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Preface 



This publication is intended for the IB" 
customer engineer (CE), and assumes that 
the CE is familiar with OLTS testing 
procedures. This publication also assumes 
that the CE is knowledgeable about VM/370 
and virtual machine concepts as outlined in 
the VM/370 Introduction . The CE must also 
be familiar with the VM/370 logon process 
as described in the V M/3 70 Ter minal User's 
Guid e,. 

This Publication is divided into four 
sections. 

Section 1 compares the environments 
available to the CE for testing and 
repairing I/O devices. The advantages of 
using the virtual machine as a tool for 
fault analysis is also described. A 
comparison of OLTS (online test system) 
results from both the real and the virtual 
system/370 is also discussed. 

Section 2 discusses the requirements for 
testing I/O devices from a virtual machine 
environment which includes the following: 

• The CE virtual machine 

• How to log onto a virtual machine 

• How to run the online tests 

• Samples of test runs 

This section provides information to 
permit the CE to run diagnostic tests in a 
virtual machine environment from a virtual 
machine console (terminal) . 

Section 3 describes the VH/370 system 
error recovery, error recording, and system 
console error messages, and the control 
blocks used in the error recovery/ 
recording process. 

Section 4 describes VM/370 facilities 
that allows more detailed information to be 
obtained for problem analysis and repair. 
These include: 



If the IBM 3767 Terminal is used, IBM 
3767 Terminal Operator's Guide, Order Ho. 
GA 18-2000, is also prerequisite. 

If the system being serviced makes use 
of the IPCS (Interactive Problem Control 
System) component of VM/370, then the 
VM/370 Inte ractive Problem Control System 
&k:S) User's Guide, Order Ho. GC20-1823 is 
also a prerequisite. 



COREQOISITE PUBLICATIOHS 

IBM Virtual Machine Facility/370: 

CP Command Reference for Genera l Users , 
Order~Ho. GC20-1820 

System Messages , Order Ho. GC08-1808 

I OS/VS, DOS/ySE. VM/370 En v ion mental 

I Re cording . Editing and Printing ( EREP ) 
I Program, Order Ho. GC28-0772 



I OS/VS, DOS/VSE, 



Environmental 



! Recording. Editing and Printing ( EREP ) 
I E£22E§.i L ogic . Order Ho. SY28-0773 

I OS/VS, DOS/VSE. VM/370 EREP Messages , Order 
| Ho. GC38-1045 

Figure 1, which follows the Preface, 
shows the relationship of VM/370 

publications to one another within the 
VM/370 Library. 



RELATED PUBLICATIOHS 



The following texts, although not required, 
will broaden the CE's knowledge of VM/370 
and virtual machines. 

IBM Virtual Machine Facility/370: 



• CPEREP and OS/VS EREP 

• Intensive Recording Mode 

• Trace Option 

• VMFDUMP 



PREREQUISITE PUBLICATIOHS 

IJJ. Virtual Machine Facility/370: 

Introduction, Order Ho. GC20-1800 

Terminal User's G ui de, Order Ho. 
GC20-1810 



Planning and S ystem Generation Guide , 
Order Ho. GC20-1801 

CMS User's Guide, Order Ho. GC20-1819 

O perat or's Guide, Order Ho. GC20-1806 

R emote S pooling Communications Subsystem 
User's Guide, Order Ho. GC20-1816. 



IBM 



3704 and 



3705 



Communications 



Controllers network Co ntrol Program/VS , 
Program L ogic Manual , Order Ho. ST30-3007. 



Preface iii 



In this publication, the ten "3330 
series" is ued in reference to the IBM 3330 
Disk Storage, Models 1, 2, and 11 and the 
IEM 3333 Disk Storage and Control, Model 1 
and 11. 

In this publication, the term "2741" is 
applicable and equivalent to the IBM 3767 
Terminal unless otherwise specified. 

The ten "3270" is used in this 
publication to refer to a series of display 
devices, naiely, the IBM 3275, 3276, 3277 
and 3278 display stations. A specific 
device type is used only when a distinction 
is required between the device types. 

Information about display terminal usage 
also applies to the IBM 3138, 3148 and the 
3158 display consoles, when used in display 
mode unless otherwise noted. 



Any information pertaining to the IBM 
3284 or 3286 printer also pertains to the 
IBB 3287, 3288 and 3289 printers unless 
otherwise noted. 

Notes; 

1. External interrupt reflection may 
cause OLTSEP Belease 4.0* 4.1* or 5.0 
execution problems; refer to the 
topic: "Invoking OLTS" for 
circumvention. 

2. VM/370 provides limited 3704/3705 BAS 
support. Although VM/370 has enough 
function to effectively utilize the 
3704 and 3705, provisions are not 
available with Release 3 to use the 
OLTTEP/OLLT/OLTT diagnostic package. 
If these test facilities are to be 
invoked then they must be used with VS 
with TCAM in a standalone System/370. 
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Summary of Amendments 

for GC20-1809-7 

VM/370 Release 6 PLC 1 



4331, 4341 PROCESSORS WITH 
CONSOLE AND 3031 AP SUPPORT 



New: Processor Support 



3278 MODEL 2A MISCELLANEOUS 



VM/370 now supports the 4331 and 4341 
processors as well as the 3031 attached 
processor. The 3278 Model 2A console 
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terminal supported by VM/370 for 
customer engineer use in conducting 
diagnostic tests. When running channel 
check handler. United channel logout is 
still available for the 4331, 4341 and 
3031 AP processors. However, there is 
no fixed or I/O extended logout area for 
these new processors. Errors corrected 
by error checking and recording (ECC) 
are not recorded by the new processors. 
Only errors corrected through processor 
retry are recorded. 



3 203 MODEL 5 PRINTER SUPPORT 



C hange d: Documentation only 

• Figure 30 has been amended to include 
further documentation of error record 
types recorded by DOS, DOS/VS, 
0S/VS1, 0S/7S2, and VM/370. 

• Correction of the default for the 
ACC= operand of CPEREP command in 
Figure 31 from NO to YES has been 
made. 

• An expanded description of the 
function of the CLEARF operand of 
CPEREP command has been added to 
Figure 32. 

• The term "error recording 
cylinder (s) N has been changed to 
"error recording area (s) " where 
applicable in the text. 

• Miner editorial changes have been 
made. 



New: Hardware Support 

VM/370 now supports the 3203 Model 5 
printer for use in hardcopying errors 
encountered during diagnostic testing of 
the system. 



Summary of Amendments ix 



Suiaary of Amendments 
for GC20-1809-6 
as updated by GN25-0476 
VM/370 Release 5 PLC 12 



ENSURING VM/370 CONTROL PROGRAM HAS ACCESS 
TO SRF DEVICE 



Changed: Documentation only 

Added to the discussion of the SRF 
device as it relates to VM/370 is the 
■eans of ensuring that the VM/370 
control program has access to the SRF. 
Also documented are the steps necessary 
to activate the SRF device. 
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YH/370 SUPPORTS THE 
PROCESSORS 



3031, 3032 AND 3033 



Hew : Processor Support 

VH/370 supports the 3031, 3032 and 3033 
processors as processors capable of 

rnnninn VM/17ft. 

Support for these processors includes 
support for the new integrated channels. 
These channels store a liiited channel 
logout, as well as an I/O extended 
logout of 640 bytes. The channels 
confori to standard System/370 channel 
interface protocol for normal operation, 
but the interface has been expanded to 
allow for signaling I/O interface 
inoperative and group inoperative 
conditions detected by the hardware. 
Such conditions, when detected, result 
in the termination of VH/370. 

CPEREP has been expanded to handle error 
records produced by these processors in 
conjunction with the SRF (Service Record 
File) 7443 device. The SRF device 
contains SRF frames that are used to 
format the records on the error 
recording area. This necessitates the 
following changes: 

• 1 new CPEREP operand, CLEARF, clears 
error records and SRF frame records 
from the error recording area, then 
writes new SRF frame records to the 
area. The CLEAR operand clears only 
error data, not frame data. 

• The CLEARHC, CLEARIO, and CLEARALL 
operands are deleted,. There is no 
longer one error area for I/O and 
another for machine checks and 
channel errors. 

From two to nine error recording 
cylinders may be defined at system 
generation. Errors are recorded in 
order of occurrence until allotted 
cylinder space is exhausted. 



Summary of Amendments 

for GC20-1809-6 

as updated by GN25-0417 

VH/370 Release 5 PLC 1 



This new support is 
following sections: 



described in the 



Section 2. VH/370 Haintenance Essentials 
Section 3. Error Handling 
Section 4. Additional CE Aids 



VH/370 SUPPORTS CHANNEL CHECK REFLECT IOH 



C hang ed: Program and Documentation 

VH/370 now reflects channel control 
checks, channel data checks, and 
interface control checks on 
user-initiated I/O events (excluding 
diagnose-initiated events, where the 
recovery process is handled by CP) to 
the user so that the user can attempt 
recovery. For diagnose-initiated 
events, the results are reflected to the 
user's virtual machine after the retry. 
If the user's SCP fails in its recovery 
attempt, the user may terminate 
operations or the task affected by the 
channel check. 



This new support is 
following sections: 



described in the 



Section 1. Hardware Haintenance — Real 
Hachine System/370 vs . 
Virtual Hachine System/370 

Section 3. Error Handling 



VH/370 SUPPORTS ONLY IPCS VHFDUHP 



Change d: Program and Documentation 

VH/370 supports only the IPCS version of 
VHFDUHP. The DHKEDH module is no longer 
contained in the system. 

"Section 4. Additional CE Aids" has been 
updated to reflect this change. 



HISCELLANEOUS 



Changed: Programming and Documentation 

Hinor technical and editorial changes 
have been made to clarify the text. 
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Section 1. Hardware Maintenance-Real Machine 
System/370 VS Virtual Machine System/370 



Host system hardware failures are caused by storage and I/O device 
errors- Most of the errors, once sense data and other information is 
analyzed, can be repaired offline (physically and/or logically 
disconnected from the rest of the system) . However, there are instances 
where offline test equipment is not adequate to simulate the fault 
condition as it occurred on the system; therefore, the system must be 
used to effect the repair. Similarly, the system must be used in a 
final diagnostic checkout of a device after it has been repaired offline 
and prior to returning the device to the customer for operating system 
usage. Another consideration for system use is to check the reliability 
of a device following an EC (engineering change) . The customer may also 
use basic diagnostics that utilize the system as an aid in the initial 
analysis of whether a system fault is hardware or software in origin. 

The previously described uses of a System/370 as a tool for the 
repair and checkout of I/O devices is addressed in more detail by the 
following discussion. Cost factors are not a consideration in the 
analysis. 



The Ideal Repair Environment -- Total Resources of a 
System/370 and Time for Problem Analysis 

Testing and troubleshooting device/storage malfuncticns cr suspected 
device malfunctions, when established local and offline troubleshooting 
techniques fail, is best achieved from an environment that is totally 
and exclusively under the absolute control of the CE. Total control cf 
a system and its resources excludes the use cf the system by other 
users, their data sets, their programs, and their hardware system 
requirements. This exclusive test mode allows the CE to use the total 
resources and power of the system in conjunction with diagnostic aids to 
track and isolate the system fault. 

There are two reasons why such an environment is ideal for the 
isolation of device faults. First, there is no contention by other 
programs for the data paths and control paths to and from the device. 
Second, any approach to troubleshooting, no matter how bizarre cr 
radical, can be undertaken because there is nc risk of destroying the 
customer's programs and data sets. However, this ideal method cf 
problem analysis is not without its shortcomings. Field engineering 
personnel CEs are only granted the total resources of a system when: 

• The malfunction to the system or to a system resource cannot be 
analyzed or repaired by offline equipment 

• The malfunction is so catastrophic that the entire system can be 
classified as unavailable to the customer 

• System preventive maintenance is to be done. Dnf ortunately, on large 
systems, this endeavor is usually scheduled en weekends or on other 
than prime shift hours. 
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Outside of preventive Maintenance work,, loss of the system to the 
customer for productive work is traumatic. The CE is placed under great 
personal stress to diagnose and repair the system and get it back in 
operation as soon as possible. 

Queued Diagnostic System Task -- Another Method 
for Fault Analysis 

As a compromise to the totally dedicated use of a System/370 repairing 
or checking out the hardware after a repair is made, it is possible with 
some online systems to place the CE diagnostic program on a task gueue. 
At times, the diagnostic task is at the top of the gueue and ready to be 
used to exercise and test selected hardware. 

The disadvantages and difficulties associated with this method of 
device repair or checkout are as follows: 

• Possible contention on data and control signal paths to or from the 
device 

• Complexity of problem analysis imposed by the programming levels and 
the gueued task diagnostics 

• Constraints of time and priorities imposed by the system operator 

• Limited flexibility in the diagnostic approach to a given problem 

Expanding on the possibility of data path and control path 
contention, suppose the CE is monitoring control signals or a 
teleprocessing line. Is the data represented en the scope or monitor 
device related to the diagnostic test or exercise or is it related to an 
"automatic" polling sequence or another control program task? If the 
data being monitored is related to another system function as well as 
the CE diagnostic activity, the problem of fault isolation becomes more 
complex and time consuming. In addition* the diagnostic test sections 
are controlled by a "driver" program (for example: CLTEP) which, in 
turn, is controlled by the operating system. This tier of programming 
overhead imposes an added level of understanding on the part of the CE 
who must repair the malfunctioning unit. 

This method of repair also requires the helF of the system operator 
who must allocate the time and the resources needed to make the repair. 
Quite frequently, the CE's request for system time tc run diagnostic 
tests is given a relatively low run priority in relation to customer 
tasks; this is particularly true if the device to be serviced by 
diagnostic programs fulfills no immediate need for the customer. In 
such situations, the CE has no alternative but to wait for the system to 
be relinquished to him. 

Another problem with this method of problem analysis is that (with 
the available diagnostic test sections and options) there are limits to 
the test patterns and loop conditions that can be used to exercise the 
failing unit. Generally, means are not provided for dynamically 
changing storage or register values to build more stringent and 
exhaustive tests tailored to the CE's own test criteria. 

The Virtual Machine -- An Alternative Method for 
System I/O Fault Analysis 

The virtual machine is a counterpart of a real System/370. It is 
generally available for use for the CE whenever the CE has a need to use 
the system. The CE can immediately use the system and diagnostic test 
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sections to check out or locate I/O faults on an I/O device after he has 
completed the virtual machine logon process (as descrited in the VH/370 
Terminal Eser^s Guide) and solicited a minimum amount of assistance of 
the system operator in attaching the failing device to the CE's virtual 
machine. 
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The CE's virtual machine, or virtual system is part or tne 
system but only a time slice utilization of it. Low storage as well as 
system registers and processor functions of the virtual machine are 
simulated by the control program (CP) component of VH/370. Protective 
features of the VM/370 System Control Program isolate and protect the 
action, programs and data sets of one virtual machine from interfering 
with the action, programs and data sets of ether virtual machines. 
Thus, operations of the CEs virtual machine have negligible effect on 
other System/370 operations. As an alternative to having the power of a 
real System/370 at a CE disposal, the virtual machine can provide 
similar functions with some sacrifice to performance. However, with the 
use of the virtual machine, there are certain timing dependencies, 
device applications and processes that are not supported by VH/370; 
these are detailed in the VH/370 System Messages under the title, 
"VM/370 Restrictions." 

The facilities provided by VM/370 and the virtual machines it 
supports are briefly described in the VM/370 Introduction. The virtual 
machine has almost the full range and capabilities of a real System/370. 
That is, it has registers and storage comparable to a real System/370. 
It has unit record devices (virtual unit record devices) called spooling 
devices that programs or data sets can utilize for punched or printed 
output. A virtual card reader is available to read data or programs 
into the virtual machine for processing. In addition, a virtual machine 
can be expanded or contracted by the use of commands that attach cr 
detach devices/resources for the exclusive use of the virtual machine 
operator. The means of controlling the virtual machine and these 
devices is through a terminal that serves as a system console for the 
virtual machine. By keying in what are termed "console function" 
commands on the terminal, simulation of many of the functions that are 
performed by buttons and switches on a real System/370 control panel can 
be accomplished. 



Some of the functions that can be simulated for 
by use of commands follow: 



the virtual machine 



ATTN, REQUEST 

ADSTOP 

DISPLAY 

EXTERNAL 

IPL 

NOTREADY 

READY 

REWIND 

STORE 



Attention interrupt from a system console 

Address stop facility 

Display storage and display register capabilities 
of a system console 

External interrupt key on the system console 

Console LOAD key 

Loss of READY to a virtual device 

READY state of a virtual device 

Function of the Tape Drive Rewind Key 

Function provided by the store key on the 
system console 
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In addition to the commands that have a direct relationship to 
function provided by the System/370 control panel and console, there are 
other commands available to the user or the system operator that can 
benefit the CE in his role as troubleshooter; these comnands and a brief 
explanation of their uses are shown in. an appendix in the VM/370 CP 
Command Reference for General Users. 

Commands that are available to the general user (and likewise, the 
CE) are described in the VM/370 CP Command Reference Guide for General 
users. The format and use of commands that pertain to all other users 
of virtual machines including the privilege class F user (that is, 
commands designed for the CE engaged in hardware maintenance) are 
contained in the VM/370 Operator's Guide, Section 4 of this bock 
contains more detailed information about the privilege class F commands. 

Online Diagnostics From a Virtual Environment -- 
Test Results 

The CE must have confidence in the virtual machine as a tool for device 
checkout and hardware debugging. But how does the virtual machine 
environment compare with a real System/370 envircnment when both use the 
same OLTS sections as the diagnostics for testing identical devices? 
The answer: very favorably. 

Tabulated results were compiled from OLTSEP OLTS test runs. Tests 
were initiated from a dedicated System/370 Model 145 (standalone) 
environment and also from VM/370's multiuser virtual machine 
environment. Concurrent testing was accomplished by the CE using OLTSEP 
and OLTS via the assigned CE's virtual machine. 

The tabulated results of OLTS indicates that only 7.5 percent of the 
140 sections tested resulted in errors that were unique to virtual 
machine operations. These errors were a reflection of those OLT 
sections that violated VM/370 architecture (see the publication VM/370 
System Messages under the topic "VM/370 Restrictions") , such as, 
dynamically-modified channel programs and time dependent routines. 

The tabulated OLTSEP/OLTS results also indicate failures that were 
generated in the standalone (dedicated System/370 environment) as well 
as in the virtual machine environment. Those errors that are common to 
both the real and the virtual system were caused by one of the 
following: 

• OLTS section fault (program) 

• Hardware malfunction 

• Hardware and OLTS were not at a compatible EC (engineering change) 
level 

• Incorrect program options selected for the devices involved 

• Incorrect hardware strapping, plugging, or switch selection 

No attempt was made to diagnose the specific reason for all of the 
indicated failures. What is significant is that all the failures that 
occurred on the standalone system also occurred in the virtual systei. 
No error detected by the dedicated system operation escaped detection 
during a subsequent run of the same OLT sections from a virtual machine. 
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The tabulated results were also indicative cf the fluid nature cf 
computing systems; neither the hardware nor the programs remain in a 
dormant state for any length of time. Either the system configuration 
changed, program test sections were updated, or the system hardware had 
teen modified by EC and RPQ changes. For the CE, maintaining up-to-date 
diagnostics that reflect the current system configuration is not without 
its problems. To help circumvent these problems, it would be wise to 
create and maintain a history file for OLTS printouts that reflects both 
virtual machine and standalone operations. This file would receive 
copies of OLTS results run in both a virtual machine and standalone 
system after ensuring that all 

• System and/or device installation site modifications have been made. 

• Sales or engineering changes to system hardware have been installed. 

• Modifications and updates to the OLTS sections are complete. 

If properly maintained, an OLTS history file can prevent unnecessary 
and time-consuming problem analysis for conditions that only reflect an 
incompatibility of program and hardware. 

The test results were obtained from a System/370 Model 145 and the 
following typical hardware mix: 

Hachine Model 

1403 N1 HS Printer 

2305 2 

2318 1 

2319 A0 
2400 5 
2540 1 
2703 1 

2821 1 CTRL Onit for Card/Printer Equipment 

2835 2 TCS Tape Drive Control Unit 

2803 2 

3145 1 

3215 1 

3330 1 

3803 1 

3830 1 Disk Control Onit 

Bear in mind that the test results did not show every OLT section run 
nor did they indicate every device supported by VM/370; rather, the test 
results indicated that with a good hardware mix, there was a typical 
error fallout. Conceivably, tests run on other System/370 VM/370 
systems would reflect similar but different inconsistencies between OLTS 
and the hardware and options involved. 

Bote: OLTS tabulations as a result of RETAIN and the 2955 interface are 
identical to the results obtained by the site CE invoking the tests (see 
"OLTSEP— RETAIN") . 

None of the tests executed in the VM/370 virtual machine environment 
resulted in a hang, reset, or loop condition of the virtual machine, nor 
was there any perceivable effect on the operations and security cf 
VM/370 and other associated virtual machines. 

Points for the CE to Consider about Virtual Machine 
Use 

As stated previously, the VM/370 Introduction will acquaint the CE with 
the power and versatility of the virtual machine. A more in-depth study 
of virtual machine use (with other operating systems operating in the 
virtual machine environment) is found in the VM/370 Operating Systems in 
s Virtual Machine. 
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With the CE*s use of the virtual machine, the following 
considerations should be made: 

• To provide all of the functions and tests described in this 
publication, the CE needs a directory entry with a privilege class F 
and G. 

• The list of VM/370 restrictions as documented in VM/370 System 
Messages should be consulted to see whether cr not the malfunction cr 
suspected malfunction is a violation of VM/37C architecture. Certain 
OLTS diagnostics violate VM/370 rules; particularly those tests that 
have time dependencies or dynamically modify channel programs. 

• Loaded diagnostics programs and related test sections reside at their 
virtual address. The virtual address is not the same as the real 
storage address unless the V=R special performance option is invoked. 

• Parts or all of the CE*s diagnostic programs may be paged out frcm 
processor storage to auxiliary storage because of concurrent use by 
the other virtual machines. The system operator can, if the 
situation warrants, lock virtual machine page (s) in processor 
storage. 

• An I/O device address may be a virtual address. The virtual address 
may be represented by its full size real counterpart, such as a tape 
drive or because it can be a logically subdivided portion of a disk 
drive (such as a minidisk) . 

• All system errors and I/O errors are not written oat to the VM/370 
error recording area; consult "Section 2. Error Handling" for 
details. If SVC 76 is used by virtual machines to effect error 
recording, then the virtual machines must meet specific parameter 
passing criteria. Also, VM/370 itself does not generate EOD and IFL 
records. No error recordings of these types are accepted for the 
VM/370 system as well as other virtual systems. Certain other error 
types are also not processed. 

• Most CCWs and CCW chains are subject to VM/370 control program 
modifications in order for VM/370 to maintain its overall paging 
environment correctly. 

• Because of the time slice technique used in dispatching virtual 
machines by the control program, the run time for diagnostic test 
sections is longer. It may be considerably longer if there is heavy 
concurrent System/370 use by other virtual machine users. 

• The system operator has control of certain special virtual machine 
options and other VM/370 options that can, if the situation warrants, 
be invoked to aid the CE and his virtual machine in problem analysis. 
Brief descriptions of these options are contained in the VM/370 
Introduction . 

• The facilities of the CMS EDIT command can be used to modify or 
create short diagnostic loops or tests for problem analysis. For 
details en this command, consult the VM/370 CMS Command and Macro 
Inference, and IhZ^lQ CMS Oser^s Guide. 

• Analysis of system and I/O problems can be accomplished by the CE 
from a remote isolated (virtual machine) terminal provided the area 
of the CE*s terminal is serviced by an BSCS (Remote Spooling 
Communications Subsystem) workstation. By using the workstation for 
the spooled output of the results of the diagnostic tests invoked 
from the terminal, the CE can make a preliminary but through analysis 
of a machine's malfunction. 
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In attempts to service components of a 3850 Mass Storage System, the 
CE should be aware that the virtual machine is interfacing with 
virtual 3330 volumes (3330V) and not with a real 3330 device; thus, 
the misapplication of diagnostics could lead to erroneous 
interpret at ions. 

In testing components of the 3850 Mass Storage System (MSS) , most 
functions provided by the online test system (OLTS) require that MSS 
activity be quiesced. To insure a quiesced mass storage system, it 
is recommended that the CE's virtual machine be run in a standalone 
environment. 

The CPOID found in the error recording records is the CPUID 
associated with the real machine and not the one associated with a 
virtual processor. 

If the facilities of an IBM 3850 Mass Storage System (MSS) are used 
with VM/370 virtual machine operations and MSS errors are reflected 
to VM/370 1 s error recording area, CPEREP must be invoked so that 
MSS-related errors recorded in the error area can be directed to an 
accumulation (ACC=Y) tape for further processing by the VS1/VS2 
Subsystem Data Analyzer (SDA) Program. Because MSS logged out data 
is voluminous and the interrelationship of MSS components is complex, 
it is imperative that this service program be used to effectively 
diagnose and isolate mass storage problems. 

The virtual machine used by the CE normally does not have a dedicated 
high speed printer. Therefore, long listings (such as console 
spooling records, dumps, error recording records, and diagnostic 
output tabulations) are queued to a common spool output device along 
with the files generated by users of other virtual machines. These 
files are queued by class as well as by the time at which the files 
are closed. If the queue for output is long or contains files that 
are sequentially ahead of the CE's output records, the wait for 
output could be quite lengthy. However, the system operator can 
alter the order (sequence) of output files, if the need is urgent. 

The I/O configuration of the virtual machine should te such that each 
virtual channel maps to real channels of a single type and model. 
This requirement is explained in detail in "Appendix E. VM/370 
Restrictions" in VM/370 System Messages. If this requirement is net 
met, the STILC instruction may return inconsistent results, and any 
data from a channel extended logout may be misinterpreted since it 
depends on the channel model. Also note that there is a restriction 
•against using control register 14 to mask out channel extended 
logouts; if this is done in a virtual machine, the logout does not 
remain pending and instead is lost. 
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Section 2. VM/370 Maintenance Essentials 



Testing from a Virtual Machine 

System operator/CE Relationship 

The CE's Virtual Machine 

Command Privilege Class for the CE 

Console Terminal Communication Considerations 

Conditions for Invoking Tests 

Input Line Editing 

The Terminal Session 

Invoking OLTS 

OLTS-FRIEND 

OLTSEP-RETAIH 

Basic Terminal Check via the MESSAGE Command 

Basic Terminal Check via the ECHO Command 



VM/370 is a system control program (SCP) that can be used on IEM 
System/370 computing systems equipped with the dynamic address 
translation (DAT) and the system timing features (STF) . 

The Online Test Standalone Executive Program (OLTSEP) and associated 
online test system (OLTS) are not part of the VM/370 system. OLTSEP and 
OLTS are ordered for the particular computer site and its related 
equipment by the customer engineer (CE) for use in diagnostic servicing. 

Maintaining and upgrading OLTSEP and OLTS test sections and the 
transfer of this data to different storage media are not a 
responsibility of the VM/370 system. Existing documentation associated 
with OLTSEP and OLTS describes these procedures. 
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Testing From A Virtual Machine 



The following conditions must be satisfied to permit testing from a 
virtual machine environment. 



1. The integrity of the complete computer system cannot be degraded to 
the point where the VM/370 program cannot be run. 

2. I/O and channel logic communication paths are operative as applied 
to OLTSEP and OLTS. 

3. The virtual machine assigned to the CE is available and 
functioning. 

4. The communication path from and to the CE's terminal is functioning 
and in an enabled state. 

5. The CE user virtual machine identification (userid) and password 
are known to the CE. 

6. The device (s) to be tested must be available for the CE's exclusive 
use. 

Note: If any of the above conditions is not satisfied, the System/370 
operations personnel must correct the situation by command entries or a 
system reconfiguration process if concurrent maintenance is desired. 
These processes are described in the VM/37C Planning and System 
Generation Guide or the VM/370 Operator's Guide. 



The hardware maintenance encompasses the following major areas of a 
system complex: the main processing unit (and the attached processor, if 
applicable) and input/output (I/O devices) . Each is maintained in a 
different way. 

• The processor (or attached processor) is maintained in a dedicated 
environment. There is no method available that allows the concurrent 
maintenance of the processor including its main storage and channels, 
while running user jobs under VM/370. 

• The I/O equipment, however, can be maintained by using online tests 
system (OLTS) under OLTSEP in its own virtual machine. It is this 
relationship that this book addresses. 
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J53ia Security 

Tapes and files created by CHS and CP do net conform to the OS or DCS 
labeling techniques, nor do their tape and disk files use the security 
protection byte found in other control systems. Files and tapes 
generated by an OS or DOS controlled virtual machine under VM/370 
supervision could contain these protection features. Therefore, the CE 
■ust proceed cautiously, since tape and disk files encountered on a 
VM/370 systea. as OITSEP, may. not restrict the CE from inadvertently 
destroying custoaer or systea data. 

Mote: This consideration arises when a disk Fack is aounted on the 
specific device dedicated to the CE's virtual machine via the CP ATTACH 
command. 
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System Operator/CE Relationship 



Working froi a virtual machine, the CE should be aware of the tine 
slicing and device sharing environment of VH/370. The management cf 
these facilities belongs in part to the system operator. The CE's 
virtual machine is also part cf the system operator's domain. The 
system operator can (if the system is large enough to sustain such 
action) dedicate devices, control units, and even channels to the CE's 
virtual system. 

The CE should be aware cf the system operator's responsibility to 
other users' virtual machines. The system operator, because of schedules 
and system workload, may not grant the CE's every request. 

The shared system responsibility of the operator and the CE manifests 
itself in situations where a CE testing from a remote location performs 
system maintenance. Through mutual cooperation and the HESSAGE and 
ATTACH commands, a complete I/O diagnostic check can be accomplished. 

The CE should also be aware that maintenance operations affect the 
throughput time of other users' virtual machine operations, and 
conversely, that other virtual machines' operations affect the 
throughput time of the CE's diagnostic operations. 

The relationship between the system operator and the CE say enhance 
I/O maintenance. This can be done by having the system operator 
exercise system options within his control. Suppose, for example, a 
problem exists and the tag lines are suspect. Oscilloscope trace 
interpretation can be difficult if many virtual machines shared the same 
bus and tag paths. To alleviate this problem, the system operator (if it 
is within his control) can dedicate a complete channel and all its 
related hardware to the CE's use. Thus, while looping on an OLTS 
routine the I/O data and control paths would be free cf other user I/O 
activity. Note also, if the system operator has access to the problem 
report file system of the Interactive Problem Control System virtual 
machine, an initial and instant analysis for the current problem by 
comparison to a base of previously reported customer VH/370 problems can 
help determine whether the malfunction occurred in the hardware or 
software. 
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The CE's Virtual Machine 



Hardware I/O maintenance can be accomplished by having the CE operate 
his own virtual machine from a terminal device while permitting other 
¥M/370 users to continue operating their own virtual machines. The CE's 
virtual machine is unique in that his CP command privilege class F 
allows him to run CPEREP to set intensive mode recording and invoke the 
NETWORK TRACE function (both these options are described later) . 

The virtual machine described below, accessed through the remote 
terminal device, provides the CE with almost all of the facilities of a 
dedicated System/370. The CE can store, display, PSW restart, IPL, 
start, and stop the program of his choice without affecting other users. 

In most instances, the CE needs no dedicated computer time for most 
of the preventive maintenance tests. There is usually little or no 
problem in being granted additional time for additional test runs if 
they are needed. The CE can be granted time to create his own 
subroutines if he so desires. This can be done by using some of the CP 
console function commands that are fully described in the VM/370 CP 
Command Reference for General Users. 

The typical CE virtual machine configuration specified in the user 
directory may consist of the following: 

USER CEMAINT PASSWORD 512K 1M GF 



CONSOLE 


009 


1052* 




SPOOL 


OOC 


2540 


READER 


SPOOL 


00D 


2540 


PUNCH B 


SPOOL 


00E 


1403 


PRINTER A 


MDISK 


190 


2314 


000 050 CMS19C R 


MDISK 


191 


2314 


010 005 CMS001 W 



The above configuration is interpreted as follows: 

• The first line contains, in left-to-right order, the user 
identification for the virtual machine, the security password, the 
normally assigned storage size, the maximum storage size the user can 
specify, and the assigned CP command privilege classes G and F. The 
G class is necessary for the CE to examine or change any values in 
his virtual machine, such as to examine sense bytes or change PSW 
values. The F class allows the CE to specify intensive recording 
mode, to invoke a trace facility to a 3704/3705 resource, or to 
invoke CPEREP to edit and clear error records. There are no other 
facilities offered with this privilege class. 

• The second line identifies the virtual console address and type. 
This entry does not need to be related to the type of terminal device 
the CE logs in on. 



*The terminal used by a CE can be any of those listed under "Console 
Terminal Communications Considerations." Some of these consoles are 
display consoles and the input, output, and attention handling 
techniques differ from document-producing terminals. If usage 
difficulty is experienced with any terminal, consult the VM/370 Terminal 
Oser^s Guide. 
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• The third, fourth, and fifth lines represent the virtual unit record 
spool devices and addresses that are mapped by the system to 
equivalent real devices. The letter B located on line four and the 
letter & located on line five represent the assigned spool class for 
that device. 

• The sixth line is an entry describing a 2314 minidisk with an address 
of 190 that contains the CMS system residence files on cylinders 000 
to 050. This disk is labeled CMS190 and this user has read-only 

(R/O) access to this disk, since it is the CMS systei disk. 

• The seventh line is interpreted the same as the sixth line with the 
following exceptions: only five cylinders are allocated to the user 
of the 2314 volume labeled CMS001. However, the write (W) access 
privilege allows the CE to write routines or modify existing routines 
and store them permanently on this disk. 

For further details on VM/370 user directory entries, see the VM/370 
Planning and System Generation Guide. 
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Command Privilege Class for the CE 



The CE's virtual machine is similar to other virtual machines running 
under VM/370. The CE f s virtual machine reacts to the System/370 machine 
instruction set in much the same manner as on a dedicated System/370. 
Control of the virtual machine is through a terminal and CP commands. 
These commands are grouped into eight privilege classes. Each class 
relates to specific system functions. The privilege class or classes of 
commands assigned to a particular virtual machine are stored in the 
VM/370 directory along with the user's virtual machine identification 
code and password. 

As a user of a virtual machine, it is assumed that the CE has the 
class G and F commands and CMS allocated for his use. CMS is discussed 
briefly in the VM/370 Introduction. CMS is important to the CE because 
this environment must be entered to execute the CPEREP command. CPEREP, 
when invoked, calls EREP modules that format and print error recording 
data; optionally* CPEREP may be used to create an accumulation tape 
(ACC=option) or edit an existing accumulation tape (HIST option) ; even 
SYS1.L0GREC data sets on tape or disks compiled from ether systems may 
be used. If the CE in a remote location has access to any of the remote 
terminals supported by the RSCS component of VM/370, he may utilize the 
facilities of RSCS to transfer bulk data, such as trace output and error 
recording printouts, to a remote printer. Remote spooling procedures 
are described in the VM/370 RSCS Oser's Guide. 

The use of CPEREP is also important in relation to its use with the 
3850 Mass Storage System. Errors accumulated on the VM/370 error 
recording area must be placed in the CPEREP accumulator output tape for 
additional processing and analysis by the VS1/VS2 subsystem data 
analyzer (SDA) program. For details on how this is accomplished, refer 
to CPEREP and OS/VS EREP in Section 4 (for a description on how to 
create an output tape) and then refer to either OS/VSJl SYS1. LOGREC 
Error Recording, Order No. GC28-0668 or OS/VS2 System ProgrammingLibrarjr 
SYSU LOGREC Error Recording. Order No. GC28-0677 for details. 

The class F commands include the SET RECORD and SET MODE commands. 
With these commands, the CE can set reguirements for intensive or soft 
error recording. Refer to "Section 3. Additional CE Aids." Class F 
allows the CE to void error recording that occurs as a result of the 
CE's virtual machine activity except for the device and condition 
specifically named in the SET RECORD command. 

Class F also allows the CE to generate trace data for a specified 
3704 or 3705 BTO (basic transmission unit) or resource by means of the 
NETWORK TRACE command. The produced trace data is then spooled to the 
CE's virtual printer. Class G commands comprise a complete set of 
commands for virtual machine use. 

In addition to the Class F and G commands, there are commands that 
are not confined to any assigned command category. These commands, 
referred to as the class "Any" commands, can be invoked regardless of 
logon status. Examples of these commands are MESSAGE and LOGON. 

This book illustrates the use of only those VM/370 commands necessary 
for CE applications. However, if additional help is necessary, the CE 
can solicit help from the system operator via MESSAGE OPERATOR command, 
or use the VM/370 CP Command Reference for General Osers, the VM/370 
Operator's Guide, and VM/370 CMS Command and Macro Reference. 
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Also be aware that, although many commands are discussed in this 
book, not all operands pertaining to these commands are discussed. Full 
descriptions of all CP and CMS commands and their operands are contained 
in the above publications. 

Included in the grouping of CP commands are those commands that might 
be used in applying a diagnostic program against a generated device 
condition. These commands may be a beneficial troubleshooting aid in a 
comparison study between virtual device reaction and real device 
reaction. 

CAUTION: Although not specifically discussed in this text, CMS commands 
exist that can destroy existing CMS files by erasure or by overlaying. 
Refer to the VM/370 CMS User's Guide for a discussion of the CMS file 
management system. 
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Console Terminal Communications Considerations 



I A console terminal is used as a communications device between the user 

I and the processor. Those devices supported by VM/370 can also be used 

j as virtual machine console terminals- Some of those devices, however, 

! need specific hardware features to facilitate VH/370 usage. For a 

I complete list of devices supported by VM/370 and used as console 

I terminals, refer to "Part 1. Planning for System Generation" in VM/370 

I Pl anni ng and System Generation Guide. 

VM/370 also supports the following IBM transmission control units 
(TCD) , communications controllers, and display control units to process 
the data to and from the terminal devices. 

Transmission Control Units and 

Communications Controllers Display Control Unit 

27(H 3271 Model 2 

2702 3272 Model 2 

2703 327U Model 1B 

3704 3274 Model 1C 

3705 3276 Models 2, 3 and 4 

The VM/370 Planning and System Generation Guide contains a list cf 
the features necessary for each device to operate in the VM/370 
environment. 

VM/370 supports virtual machine operation through the user»s terminal 
linkage to the system. Each terminal type uses its own communication 
language, data transmission speed, and communication seguence technique. 
Therefore, for intelligent and meaningful data transfer between each 
user and his virtual machine, use of the correct translation tables and 
command seguences must be established. 

I EBCDIC is the code used by the hardware logic of all VH/370 supported 

j devices listed in "Part 1. Planning for System Generation", VM/37 

I Pl ann ing and System Generation Guide. One exception is the 2711 which 

I uses either PTTC/EBCD or Correspondence code. 

The supported terminal devices can be categorized as belonging to 
either IBM Terminal Control Type 1 or IBM Telegraph Terminal Control 
Type 2. 

For a list of the features and RPQs necessary for VH/370 usage of 
these terminals and consoles, consult the VM/370 Planning and .System 
Generation Guide. 

VM/370 system generation defines to the operating system the physical 
hardware components on that system. This entails matching the 
hexadecimal hardware address of that device to a device type designation 
(for example, 2314). This is necessary so that data communication 
between the processor program and the devices is decipherable and 
meaningful. This is accomplished by using the correct translation 
tables for terminals and consoles. In VM/370, this merging of address 
to device type is done for all devices except 1052s, 2741s, and 3767s. 
The 1052s and 2741s can reside on any remaining available 
telecommunication lines. The matching of the device transmission code 
to a designated line address is a function of the enabling sequence to 
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Determination of whether the device on the enabled line is a 1052 cr 
a 2741 is handled by the initial communication sequence between VM/370 
and the terminal. This is illustrated in Figure 2. VH/370 handles the 
3767 terminal and the 2741 terminal identically, 
that device and the deciphering of the LOGON (or DIAL) command. 



/ I 

/ TERMINAL |<- 

r- 1 I 

i 1 



(C)/02 



This message is sent 
on the enabled line. 



I I 

| SYSTEM | 

I t 



/ 



/ fmJDMTlUlT I. 



No Response or (Y) Response 



->! SYSTEM | 



No Response = 2741 
(Y) Response = 1052 and PTTC/FECD Keyboard 

Figure 2. VM/370* s Terminal 1051 or 2741 Determination Procedure 

The code that the 2741 Terminal uses — PTTC/EECD or Correspondence — 
is determined by deciphering a privilege class any command. For a 
complete list of these commands, see the VM/370 CP Command Reference for 
General Users* One of these CP commands is the LOGON command shown in 
Figure 3. 



/ I 

/ TERMINAL |- 
I 



LOGON Command 



I I 

>| SYSTEM | 

! I 

i 1 



Figure 3. Determining the Line Transmission Code for the 2741 



Code determination is done by the program examination of the LCGCN 

word initiated at the beginning of the terminal session. Deciphering 

LOGON or any valid contraction of LOGON followed by a blank character to 

one of the two codes, establishes the code to the applicable terminal. 
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Figure 4 indicates the differences of the two codes involved with 
LOGON. 
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Figure 4. Code Comparison Using the LOGON Command 



The merge of device type, transmission code, and line address is 
indicated in the RDEVBLOK (Real Device Block) applicable to that virtual 
machine. 

The RDEVBLOK is defined as storage area that contains a specific 
number of doublewords that describe the characteristics, and other data 
applicable to a designated device. (These blocks of data are shown in a 
formatted dump output. See VMFDUMP in Section 4) . Nested in this block 
of data is the device type and its communication code (PTTC/EECE, 
correspondence, APL, and so forth) . 

RDEVBLOK information is available to the program support 
representative, who has privilege class E command access to the CP 
storage areas that contain the control blocks associated with CP and 
virtual machines. The command classes assigned to the CE (classes G and 
F) do not permit display of VM/370 control program areas. In VH/370, 
the 1052 and 3215 are architecturally and functionally equivalent. 
Therefore, the 1052 and 3215, along with 3210 and 215C, all equate to 
the same hexidecimal equivalent. This causes the output of the 0ER 
summary records to reflect the device type as a 1052 rather than as a 
real device type. 
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Conditions for Invoking Tests 



r* ^ _ o ^ i : „ u. : i :*.. 

riuuesaui nciiauiiny 

VM/370 and the system it runs on must achieve a basic reliability for CE 
diagnostic use. This is achieved by hardware configurations that meet 
VM/370 criteria for system generation. Refer to "Part 1. Planning for 
System Generation", in VM/370 Planning and System Generat ion Guide for a 
complete list of devices, model numbers, and features supported by 
VM/370. VM/370 Planning and System Generation Guide also gives sample 
hardware configurations that comprise the minimum system requirements 
for running VM/370 after system startup- 
Service time might be arranged for CE diagnostic or maintenance usage 
of spooling devices and tape drives after system generation and 
initialization procedures are complete. This is possible since VM/370 
may be able to continue operating for a short time without the 
availability of these devices. The availability of the spooling devices 
and tape drives for CE diagnostic testing, however, depends on 
priorities established by system initialization personnel. When 
availability has been established with the system operator, these 
devices can be placed offline for service. 

Note; In attached processor operations, a serious malfunction on the 
attached processor could cause uniprocessor mode on the main processor. 

Basic VM/370 performance adequate to run diagnostic tests can be 
assumed if the CP MESSAGE command correspondence between the CE and the 
system operator can be established and the system performs and responds 
to other requests and queries of system personnel. 

Hookup to the Test and Diagnostic Residence 
Device 

System diagnostic OLTSEP and OLTS normally reside on a tape or a disk 
pack. Therefore, besides establishing a path to the device to be 
tested, a data path must be established to the device that contains the 
test. This is done by having the system operator mount the pack cr 
load the tape containing the diagnostics (assuming that the CE is at a 
remote location) onto a suitable device. The operator must then prepare 
the test device that is to be used (insert cards, tape, make the device 
"ready", and so on) by the diagnostic tests. The operator then, by the 
use of the ATTACH command, attaches these devices to the CE»s virtual 
machine. 

Hote: Only the system operator with the proper privilege class can 
invoke the ATTACH command. After the ATTACH command has been invoked, a 
confirming message to that effect appears at the CE's console. To 
achieve this, the CE must have previously legged onto his virtual 
machine. 

Successful Logon 

Successful logon indicates terminal and communication path reliability, 
CE virtual machine accessibility, and compliance with VM/370 logon 
requirements. 
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Logon is successful if the terminal responses progress as far as the 
LOGMSG. 

Example 

vm/370 en line ijh359 qsyosu 

logon ce 
ENTER PASSWORD 

LOGMSG-08:04:35 03/30/74 



If LOGON is not accomplished, one of the following has occurred: 

A 2741 terminal is connected to VM/370 via a 3704/3705 line in NCP 
(network control program) mode. The Return key must be pressed 
before the "vm/370 online" message appears at the terminal. 

The user's terminal is connected to a 3704/3705 line that is in NCP 

mode and has the Multiple Terminal Access (MTA) feature. The MTA 

feature reguires special sign-on procedures (see VM/370 Terminal 
Dser^s Guide for details) . 

The data path between the control unit and the terminal is incomplete 
or the terminal itself is not operational. 

The virtual machine does not exist or is already in use by another 
user. 

LOGON procedures or VM/370 terminal entry rules have been violated. 

VM/370 program not operational. 

Successful logon would exceed current system operating parameters; 
therefore, it is not allowed. 



LINE AND TERMINAL FACILITY CHECK 

Data path failure or VM/370 not operational may result in failure to 
receive the "vm/370 online" message. This problem can be resolved by 
communicating to the computer site to determine whether or not VM/370 is 
indeed operational and if the terminal in question is online and enabled 
to the system. If the system operator response is affirmative, then 
local testing and communication line checks should be initiated. 

Violation of VM/370 terminal logon procedures may prompt the terminal 
message "restart." In this situation, use the VM/370 Terminal Oser's 
Guide to recheck the logon procedures. If satisfied that the procedures 
invoked are correct, check the device for correct local operation, then 
initiate tests to check the data path to the control unit. 
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If the CE receives "virtual machine already in use," or "...exceeds 
system parameters" in addition to "vm/370 online" and possibly RESTART, 
use the MESSAGE command and contact the system operator for assistance. 

To invoke the MESSAGE command for communication to the system 
operator any of the following forms may be used: 

message operator message-text 
msg op message-text 
m op message-text 

If a message response from the system operator is not forthcoming or 
the message cannot be entered via terminal equipment, then other media 
must be used to establish communication with the system operator. 

If an acknowledgement of the message is received by the CE, then line 
and terminal communication have been successfully established. 



USING THE LOGON COMMAND 

If line and terminal performance is satisfied, failure to log on can be 
the result of improper use of the LOGON command and its associated 
operands. The correct procedure involves knowing the correct password 
and CE userid. 

Assume that the LOGON was invoked correctly but the response was a 
facsimile of one of the following: 

MAXIMUM USERS EXCEEDED 

INVALID USERID 

USERID NOT IN CP DIRECTORY 

PASSWORD INCORRECT 

ALREADY LOGGED ON LINE raddr 

CE action should be to relay this data via the MESSAGE command back 
to the system operator. The system operator can then defer maintenance 
to a later time period, or can arrange an environment so that CE LOGCN 
is successful. Once logon is successful, the CE can use OLTSEP and the 
online test sections (OLTS) . Samples of invoking OLTSEP are shown later 
in the text. 

To assist in the process of entering the tests or other data, the CE 
can use VM/370's four input line edit functions; they are described in 
the VM/370 Terminal User^s Guide. Briefly, an 3 symbol when entered 
deletes the previously entered character on the logical input line. The 
t symbol deletes the previously entered input line. The # symbol is 
used to signal the end of a logical input line so that multiple logical 
input lines can be entered on the same terminal input line. The " 
symbol is issued as an escape character, that is, it cancels the line 
edit function of a following 3, #, 2, or " character and allows that 
line edit function character to be accepted as data. 

After successful logon, the CE must enter the environment needed to 
perform the function he desires. To store or display storage or 
registers in the virtual machine, the environment to use is CP; to 
invoke CPEREP to edit error recording, the CE must first perform an IPL 
and enter the CMS environment. To use the online test sections, the 
OLTSEP prograi must be loaded into the virtual machine. Details en 
logon, the initial program load (IPL) operation, and the virtual logoff 
process (ending the terminal session) are described in VM/370 Term in al 
User*s Guide- 
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Invoking OLTS 



To load the OLTSEP and OLTS programs from a tape or a disk, the CE must 
have the operator attach the IPL device containing the tests to his 
virtual machine. This can be accomplished by asking the operator, or, 
if the CE is at a remote location, the CE can communicate by sending him 
messages on a terminal such as the following: 

msg operator mount my diagnostic pack on 181 - ce 

msg operator put scratch tape on 583 - test device 

The operator will then mount and make ready the devices desired fcr 
testing by the CE. The operator then issues the ATTACH command; the 
CE's terminal then indicates: 

DEV 181 ATTACHED 
DEV 583 ATTACHED 

In the case of system-owned volumes (DASD devices) that cannot be 
directly attached to the CE's virtual machine, testing is facilitated by 
defining the device as a full extent minidisk with a relocation factor 
of (that is, the DASD device is described in the system with its 
minimum and maximum cylinder values) . The CE can then use the LIHK 
command to link to the device (via password identification) in write 
mode to execute the prescribed tests. 

Under these conditions, the diagnostic used must confine its write 
operation to the CE cylinders only. Use of system owned disks by the CE 
can be achieved by directory entry in the CE's virtual machine or by the 
use of the LINK command. 

The CE is now ready to load his virtual machine with OLTSEP. This is 
done by issuing the IPL command to the addressed device. Open 
completion of the operation, OLTSEP responds to the CE's terminal as 
though he were using the real system console (3215, etc.) . Figure 5 
shows a sample of the complete logon operation, OLTS testing, and logoff 
operation as initiated from a 2741 console. The 2741 sample session 
shown in Figure 5 would suffice for diagnostics run from a display 
terminal. The major difference is that the exclamation point is net 
indicated en the screen's output area; instead, a change in screen 
status information is indicative of attention signaling. 

Notes: 

1, While the execution of OLTS in a virtual machine is usually 
identical to execution on a real machine, differences exist fcr 
specific types of test devices. Terminal control devices (2701, 
2702, 2703, 3704, and 3705) often appears to respond differently to 
tests executed in a virtual machine. A control run should be 
executed against a device that is known to be operating correctly, 
and the error shown should be considered the normal results when 
the OLTS are run in virtual machine. 

2. If the OLT section selection (DEV/TEST/CPT) defines the same 
terminal that is serving as the virtual system console, refer to 
the topic, "Invoking OLTS to Virtual Machine Console Terminals." 
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vm/370 online xdhxjr qsyosu 

logon ce 

ENTER PASSWORD: 

LOGHSG - 08:04:35 03/30/76 

* CP/CMS 

* COLD START 16:30 

LOGON AT 08:32:14 EST THURSDAY 03/30/76 

msg operator attach oltsep tape on 382 as 382 < (Note 1) 

TAPE 382 ATTACHED 

msg operator attach dasd 333 as 333 < (Note 1) 

DASD 333 ATTACHED 
CP 

define 009 as 01f < (Note 2) 

i 382 < (Note 3) (see Note 4 if OLTSEP Release 4.0- 4-1- or 5.0 

is being used) 
04 SEP188D ENTER DATE IN FOLLOWING FORMAT 'HM/ED/YY' 
r 04, ' 03/17/72* 

04 SEP330D ENTER TIME IN THE FORMAT 'HH.MM.SS* 
r 04, '08.30.00' 

SEP392I OLT LOAD ADDRESS IS 020000 HEX. 
log 
LOGOFF AT 08:41:13 ON 03/30/76 



Notes: 

1. Messages to the operator to attach devices is necessary only if 
the CE invokes tests from a remote site. In most cases, the CE 
is on-site and simply asks the operator to fulfill his requests 

2. Normally, system consoles have an address of 01F. Therefore, 
assembled diagnostic tape reflects this address. Virtual 
consoles are configured as 009 in the system directory. To 
resolve the conflict of different addresses, the DEFINE command 
is used as shown. If the CE wishes to run diagnositc excerises 
on his own virtual console, he should see the topic "Invoking 
OLTS to Virtual Machine Console Terminals." 

3. Initialize and load the device that contains the OLTSEP and 
OLTS program. 

4. Loading OLTSEP Release 4.0, 4.1, or 5.0 into the VM/370 
environment may cause the program to enter a loop condition 
because of the manner in which external interrupts are 
processed. To circumvent this problem, the CE can, before 
issuing the IPL command, either: 

a. Turn off the virtual machine's interval timer by issuing: 

set timer off 

b. Initially set the virtual machine's interval timer to a 
maximum value via the STORE command, thus: 

store 50 ffffffOO 

i . 

Figure 5. 2741 Printout — A Typical CE Terminal Session DsiDg 
OLTSEP-OLTS (Part 1 of 2) 
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SEP102I 0L1S RUNNING 

SEP107I OPTIONS ARE NTL,NEL,NPP, FE,NMI, EP, CP, PR, SI,NRE 

01 SEP105D ENTER DEV/TEST/OPT/ < (Note 5) 

r oi^aaa/asaoa-z/nfe^pca)/ 1 

SEP158I S T3830A DNIT 0333 

SEP210I ROUTINE 0003 BYPASSED, MANUAL INTV REQUIRED. 

SEP158I T T3830A UNIT 0333 

! < (Note 6) 

PBftflrftT f m ** r\ -* /\ »% OTm-^m rt -°i -t -* 

JirUOi O 1JOJUJ] Uflli' \J333 

CP 

log 

LOGOFF AT 08:41:13 ON 03/30/76 



Notes: 
5. 



6. 



Description of OLTSEP test options are disclosed in the CE 
document IBM Maintenance Program: OLTSEP Operator's Guide, 
Order No. D99SEPD. 

Observe that in this example, a long string of OLT sections 
were requested to run on unit 0333. The exclamation point (!) 
indicated is produced by the CE pressing the attention key twice 
quickly on the console. This allows the CE to enter the CP 
environment to perform some virtual machine function; and, at 
the same time, temporarily suspends the previously engaged 
operation. In this instance, the CE chose to log off the 
system. This action relinquishes the user's allotted storage 
and temporary disk space, which then can be allocated to other 
users. If, however, the program OLTS sections were not 
interrupted, the program would have concluded normally by 
reissuing the following line at the conclusion of the current 
set of test requests. 

01 DEP105D ENTER DEV/TEST/OPT 

This response indicates that new values are to be entered for 
subsequent test runs. 



Figure 5. 2741 Printout — A Typical 
OLTSEP-OLTS (Part 2 of 2) 



CE 



Terminal Session Using 



INVOKING OLTS TO VIRTUAL MACHINE CONSOLE TERMINALS 
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one program m 
As a case in 
virtual conso 
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n occur where the CE may wish to initiate OLTSEP and run 
on the same device. In such cases, spurious results can 
reason for this is that the data and control path to the 
ing used by two independent programs and, as a consequence, 
ntrol switches set within the control unit or the device by 
ay be incompatible with the operation of the other program, 
point, assume a CE wishes to run diagnostic tests on his 
le, a 3277. The CE logs onto the VM/370 system, loads 
irects the OLT sections to be run on the same terminal, 
a nonformatted screen. The display screen has previously 
ed by VM/370 to be compatible for its own use. Thus, 
ults are dissimilar to expected OLT test patterns. 



To circumvent this, the CE must logon to another terminal and then 
have the system operator attach the 3277 to be tested to the CE*s 
virtual machine (using the real device address) . By exercising the 
device in this manner, any conflict in the use of control and data paths 
is avoided. 
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It is permissible, in some cases, to designate the virtual console as 
the test device without great conflict. The reason for this is that 
OLTS and VM/370 service the device in a similar manner. The 2741 
serving as the virtual console and as the test device falls into this 
category. Use Figure 5 and substitute values. 



Section 2. VM/370 Haintenance Essentials 27 



OLTS-FRIEIMD 



A sample of an OLTS-FRIEND operation invoked from a virtual machine 
environment is shown in Figure 6. To make the example more meaningful 
consult IBM Maintenance Program — Online FRIEND OS/EOS (D99-0200A) . 
Observe that invoking OLTS-FRIEND employs the same mechanics as invoking 
other OLTS sections from a System/370 environment. 



r 



logon ce 

ENTER PASSWORD: 

LOGMSG - 9:35:28 03/30/76 

♦PLANNED SHUTDOWN AT 1700 TODAY FOR HDWR ADDN 8 PROGRAM CHANGE 

♦QUERY LOG FOR ADDITIONAL DATA 

LCGON AT 11:24:45 EST WEDNESDAY 03/30/76 

TAPE 381 ATTACHED 

DASD 131 ATTACHED 

CP 

ipl 381 

DISABLED WAIT STATE. CP ENTERED; REQUEST, PLEASE< — (Note 1) 

CP 

query lines 

CONS 009 ON DEV 04B< (Note 2) 

st b48 00000009 

STORE COMPLETE 

ext 

04 SEP188D ENTER DATE IN FOLLOWING FORMAT 'MM/ED/YY 1 

r 04, '03/30/76* 

04 SEP330D ENTER TIME IN THE FORMAT 'HH.MH.SS' 

r 04, » 03/30/76 • 



Notes: 

1. OLTSEP expects a console address of 01F tc be used as the 
input device for inserting OLTS and device values. The 
virtual console address was assigned at system generation time 
and resides in the user directory. When CLTSEP attempted to 
send a message to the console address specified ty storage 
location E48, CP recognized that no such virtual device 
existed; therefore, the virtual machine's OLTSEP operation was 
suspended and the virtual system entered the wait state in the 
CP environment. To resolve the differences between the 
console addresses, the CE can either change the virtual console 
address or redesignate the console address called for in the 
OLTSEP program. In this example, the CE chose the latter 
technique by employing the CP QUERY command to find the virtual 
address of his console. Then, using the CP STORE command, 
placed the address in the proper OLTSEP program location. 
Resumption of OLTSEP operation is invoked by using the CP 
EXTERNAL command (the virtual machine's external interrupt), 
interrupt) . 

2. 009 indicates the virtual console address and 04E represents 
the true line address to which the terminal is connected. 

i - — —j 

Figure 6. 2741 Printout — A CE Terminal Session Invoking OLTS-FRIEND 
(Part 1 of 2) 
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SEP302I OLT LOAD ADDRESS IS 020000 HEX. 

SEP102I OLTS RUNNING 

SEP107I OPTIONS ARE NTL,NEL,NPP, FE,NMI, EP, CP, PR, SI,NTR 

04_ S£P445D E»TER D-EV/TEST/OPT/ 

r 01,'131/t0200a//« 

SEP 1251 UNREADABLE LABEL ON 0131 

SEP137I CSi 000104600E000005 

SEP137I SNS OOO80O40O70O0O000000000000000GC00CG000CCC000C0O0 

04 SEP139D REPLY B TO BYPASS, R TO RETRY, P TC PROCEED 

r 04, 'p* 

SEP158I S T0200A UNIT 0131 

SEP100I FRIEND RUNNING - V/L=10 

SEP100I DATA AREA IN BYTES = 122864 

04 SEP120D CAN VOL DATA ON 0131 BE DESTROYED. REPLY *ES CR NO. 

r 04, •yes 1 

SEP100I ALL OF DEVICE 131 ALLOCATED 

04 SEP101D ENTER FRIEND COBKANB 

r 04,»seek/cyl=50/hd=00» 

04 SEP101D ? 

r 04,»rh into $a' 

04 SEP101D ? 

r 04, •go 1 

04 SEP101D ? 

r 04,'duip $a' 

SEP100I 02200E 00003200 00000000 00000000 CCCC0000 

04 SEP101D ? 

r 04, 'end' 

SEP FRIEND ENDING 

SEP158I T T0200A UNIT 0131 

SEP107I OPTIONS ARE NTL,NEL,NPP, FE,NMI, EP, CP, PR, SI,NTR 

01 SEP105D ENTER DEV/TEST/OPT/ 

t 

CP 

logoff 

LOGOFF AT 11:52:02 ON 03/30/76 

i 1 

Figure 6. 2741 Printout — A CE Terminal Session Invoking OLTS-FRIEND 
(Part 2 of 2) 
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OLTSEP-RETAIN 



To invoke the facilities of RETAIN/370 through the media of OLTSEP in a 
virtual machine, the following must be invoked in the order listed. 

1. Establish line communication to RETAIN center. 

2. Using the CE meter key, turn the "degate interface" lamp off on the 
2955. 

3. Enable the 2955 via the enable/disable switch. 

4. The CE legs onto the system from a terminal. 

5. The system operator, per the CE's request, will vary the 2955, test 
device (s) and the OLTSEP device online. 

6. The system operator, using the ATTACH command, connects the 
device (s)/line(s) to the CE*s virtual machine. 

7. The CE issues an IPL command to the device that contains OLTSEP. 

8. The CE provides the date and time in response to the date and time 
prompt message and then to the following message: 

01 SEP105D ENTER DEV/TEST/OPT/ 
The CE responds with: 

r01,'rei < (Retain input request) 

The system, if it honors the request, will respond with 

SEP163I * RETAIN/370 READY 

01 SEP105D ENTER DEV/TEST/OPT/ 

From this point on, the on-site CE and the operator at the RETAIN 
remote location can communicate via terminal action by using the 
Response 3 format as shown: 

R 03, 'message 1 

Device testing can be invoked by either the RETAIN site personnel cr 
the on-site CE after the initial test on the specified device was 
initiated by the on-site CE and RE is specified in the option field. 

The terminal data that appears on one terminal will be a replica cf 
the data that appears on the other terminal after hookup conditions are 
satisfied. 

HP-tej. Be aware that the RETAIN operation utili2ing the OLTS tests from 
a virtual environment is subject to the same restrictions as are other 
programs run in other VM/370 virtual machines. See VH/370 System 
Messages for the list of VM/370 restrictions. 

A result of an OLTSEP/RETAIN operation is shown in Figure 7. 
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vb/370 online ljh359 qsyosu 

1 ce 

ENTER PASSHORD : 

service 

BMKLOGG92E DEV 009 NOT DEFINED; CONS 009 ALREADY DEFINED 

DMKLNK108E CE 230 NOT LINKED; VOLID PIDSK1 NOT MOUNTED 

LOGMSG - 08:57:37 EDT FRIDAY 03/30/76 

* RUNNING SYS056 IPL3 

LOGON AT 09:35:54 EDT FRIDAY 03/30/76 

DMKDSP450W CP ENTERED; DISABLED WAIT PSW 

CP 

isg op attach 380 to ce as 380 

b op attach line 080 to ce as 080 

m op attach oltsep to 137 as 137 

TAPE 380 ATTACHED 
define 009 as 01f 
DASD 137 ATTACHED 
CONS 01F DEFINED 

LINE 080 ATTACHED 

i 137 

04 SEP188D ENTER DATE (AND TIME) -'HM/DD/YY,HH/MH/SS' 

r 04*03/30/76, 11/00/00' 

SEP392I OLT LOAD ADDRESS IS 020000 HEX. 

SEP102I OLTS RUNNING 

SEP107I OPTIONS ARE NTL,NEL, FE,NMI, EP, CP, PR, SI, NTR 

01 SEP105D ENTER DEV/TEST/OPT/ 

r 01,'rei' < (initial RETAIN request) 

SEP163I * RETAIN/370 READY 

01 SEP105D ENTER DEV/TEST/OPT/ 

r 01,'380/2400a/nfe,re/» < (Initiated ty site CE. 

Note: re=RETAIN option) 
SEP119I NON-STANDARD TAPE LABEL ON 0380 
04 SEP139D REPLY B TO BYPASS, R TO RETRY, P TO PROCEED, HAY DESTROY 

DATA 
r 04,'p' 

SEP158I S T2400A $ UNIT 0380 
SEP 1581 T T2400A $ UNIT 0380 

SEP107I OPTIONS ARE NTL,NEL, NPP, NFE, NMI, EP, CP, PR, SI, NTR, RE 
01 SEP105D ENTER DEV/TEST/OPT/ 

R01,'/2400A-D//» < (initiated by RETAIN site) 

SEP158I S T2400A $ UNIT 0380 

SEP158I T T2400A $ UNIT 0380 

SEP158I S T2400B $ UNIT 0380 

SEP158I T T2400B $ UNIT 0380 

SEP158I S T2400C $ UNIT 0380 

SEP158I T T2400C $ UNIT 0380 

SEP158I S T2400D $ UNIT 0380 

SEP158I T T2400D $ UNIT 0380 

SEP107I OPTIONS ARE NTL,NEL, NPP, NFE, NHI, EP, CP, PR, SI, NTR, RE 

01 SEP105D ENTER DEV/TEST/OPT/ 

r 03, , is this test sufficient?' < (Message from site CE) 

01 SEP105D ENTER DEV/TEST/OPT/ 

R 03,' YES THANKS TERMINATE OPERATIONS' < (Response from RETAIN) 

01 SEP105D ENTER DEV/TEST/OPTION/ 

! ! < — (Attention key hit twice to enter CP environient for logoff) 
CP 
log 

LOGOFF AT 11:41:05 ON 03/30/76 
i i 

Figure 7. 2741 Printout — Terminal Session Showing Use of RETAIN/370 
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Basic Terminal Check Via the MESSAGE 
Command 



By the use of the MESSAGE command, basic terminal checkout can be made 
at any time VM/370 is operational and the related interface to the 
terminal is enabled.* The MESSAGE command, a CP command, can be used by 
any user on any terminal prior to and after the LOGON operation. With 
the MESSAGE command, the CE can: 

• Send a message to any logged on user 

• Solicit a response from the System Operator 

• Send a message to himself 

The requirements for the basic check of a VM/370 terminal and line 
condition are: 

— The VM/370 program must be operational 

— The teleprocessing line must be enabled or the related 3704/3705 
loaded, ready, and its resources enabled 

— The MESSAGE command format must be familiar to the CE 

— The keyboard must be unlocked 

The format of the MESSAGE command is described in the VM/370 CP 
Command Reference for General Osers. Essentially, you enter the command 
MESSAGE, MSG, or a valid contraction of MESSAGE. Then, the user 
identification of the virtual machine that is tc receive the message is 
entered, followed by the message text. However, if you are sending a 
message to yourself use an asterisk (*) in place of the userid. 

When the asterisk (*) operand is used prior to a successful logon 
operation, the system creates a VMBLOK and then unites the LOGCH 
keyboard with the line address (XIX) . This is the three-digit 
hexadecimal address of the 270x communications line that connects to a 
terminal device. This is indicated in the response. 

Note: If the asterisk (*) operand is used after logon, then the valid 
userid is inserted in response messages. 

The following is an example of a basic terminal and line checkout 
without involving logon procedures using a 2741 terminal. Assume that 
terminal hookup has been established per instructions outlined in the 
VM/370 Terminal Oser^s Guide and that the terminal is placed in 
COMMUNICATE mode. 



*If the terminal is a 2741 connected to VM/370 via a 3704/3705 line in 
NCP mode, the Return key must be pressed before the "vm/370 online" 
message will appear at the terminal. If the terminal device is 
connected to a 3704 or 3705 line that is in NCP mode and has the MTA 
feature, an additional terminal sign-on procedure is necessary in order 
to use the MESSSAGE command prior to the LOGON operation (see the 
IJ3Z370 Terminal User_«.s Guide for details) . 
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Example 

vm/370 on line < (ATTN key [or its equivalent] pressed) 

msg * abcdefghijklmnopqrstuvwxyz0123456789 
(text of message sent to self) 

MSG FROM LOGON058: ABCDEFGHIJKLMKOPQBSTDVUXYZ0123456789 
(response of message to self prior to logon) 

Note: VM/370 normally translates lowercase alphabetic data to uppercase 
in responding to terminal MESSAGE commands. 
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Basic Terminal Check Via ECHO Command 



Assume that the CE can successfully logon tc his assigned virtual 
■achine. Assuae also that his terainal is failing because of a local cr 
line condition. In such a situation, instead of invoking OLTS, the CE 
can invoke the CP ECHO coaaand tc exercise the terainal. ECHO aay serve 
as an adequate test for printing and keyboard probleas. 

The ECHO coaaand differs froa the MESSAGE coaaand in that there is no 
translation tc uppercase letters in processing the coaaand text. That 
is, the coaaand will be returned to the terainal in the saae fora in 
which it was transaitted. The ECHO coaaand is exclusive to the G 
privilege class. 

Inforaation on the foraat and use of the ECBO coaaand is detailed in 
the VM/370 CP Coaaand Reference for General Users. In suaaary, to use 
the ECHO coaaand, you Bust be legged onto your virtual aachine and ycu 
aust be in the CP environaent. With these conditions satisfied, ycu 
enter the ECHO coaaand and specify the nuaber of tiaes you want the 
aessage that you will enter returned to you. after this is done, the 
systea proapts you for the aessage text. If the ECHO coaaand is entered 
without the return aessage value, ECHO will default to one response fcr 
each line entered. 

Figure 8 is a terainal session using the CP ECHO coaaand. 



r 



va/370 online Xdhxjr gsyosu 

logon ce 

ENTER PASSWORD: 

LOGMSG - : 35:28 03/30/74 

♦RUNNING SYS009 - DIRECTORY CHANGE SCHEDULED AT 1800 

♦QUERY LOG FOR ADDITIONAL INFORMATION 

LOGON AT 11:24:45 WEDNESDAY 03/30/74 

CP < virtual aachine is in the CP environaent 

echo 3 < echo environaent entered; three responses elected 

ECHO ENTERED: TO TERMINATE TEST TYPE END 
ENTER LINE 

NOW is THE tiae < (text plus return key depression) 

NOW is THE tiae < (three systea responses) 

NOW is THE tiae 
NOW is THE tiae 

end < (end entered by CE to exit froa ECHO environaent) 

CP < (systea now back in CP environaent; echo test coaplete) 



Note: It is iaperative to type "end" at the end of the test inasauch 
as a subsequent coaaand entered would be treated as ECHO text. 

i 

Figure 8. 2741 Printout — A CE Terminal Session Invoking ECHO Coaaand 
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Section 3. Error Handling 



Overview of I/O Error Handling 
Environmental Data Recording 
Error Recording Area 
Recovery Management Support 
Machine Check Handler 
Channel Check Handler 
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Overview of I/O Error Handling 



In attached processor systems, only the main processor has real I/C 
processing capabilities. Therefore, when the attached processor 
encounters channel operations, the channel program is reflected to the 
main processor for execution- I/O operations and I/O error recording 
for attached processor systems are no different from the techniques 
employed on uniprocessor systems. 

I/O events initiated by CP fall into one of t«o general categories: 
CP I/O Requests: 

• Paging 

• Spooling 

• CHS I/O (diagnose interface) 

Virtual User Requests: 

• Any I/O request issued by an operating system running in a virtual 
machine 

When an I/O event results in an I/O error, the action taken by CP 
depends on the type of request: CP-related request, or virtual user 
request. Since each virtual machine is a functional equivalent of an 
IBM System/370 and its associated I/O devices, CP reflects virtual 
machine I/O errors to the virtual machine that initiated the I/O event; 
this is done so that the errors appear the same as if the user were 
running standalone on a real machine. Device error recovery, errcr 
recording, and messages issued to the operator of the virtual machine 
depend upon the virtual machine's operating system, release levels, and 
other data, and are not part of CP. 

I/O error recovery is attempted for CP-initiated I/O operations to 
CP-supported devices, and for virtual user I/O operations initiated 
through VH/370*s Diagnose Interface, which is mainly an interface for 
CHS. 

When channel status word indicators show that an error occurred 
during a CP-initiated I/O event, a device-dependent error recovery 
procedure is invoked and a cycle of restarts begins that continues 
either until the error is corrected or until it is determined to be 
fatal (uncorrectable) . The controlling routine of the cycle is the I/C 
error recovery routine which, upon exit, may indicate that: 

• The activity is to be retried 

• The error is fatal 

• The error has been corrected 

If the I/O error recovery routine indicates that the I/O event is to 
be retried, the I/O supervisor queues the I/O request for processing. 
The restart takes place when the channel restart routine, during its 
normal processing, initializes the I/O operation. After the I/C 
activity is completed, the I/O supervisor tests the reccvery-in-progress 
bit and causes control to return to the I/O error routine, even if no 
errors occurred during the retry. 
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I/O error routines count the number of retries and indicate to the 
I/O supervisor that the error is fatal when the Maximum allowable number 
has been reached. When an I/O error routine indicates that an error 
condition is fatal, the I/O supervisor places a "permanent error" return 
code in the user»s IOBLOK and returns control to the caller. 

An error is considered to be corrected when no errors occur during a 
retry of the I/O activity. For corrected errors, the I/O supervisor 
places a "completed without error" code in the user's IOBLOK, updates 
Statistical Data Recording (SDR) counters in the 5DRELQK, then continues 
processing as it would have if there had been no error the first time 
the activity was attempted. 



I/O Error Recording and SVC 76 

Eecause the IBM operating systems that are commonly run in virtual 
machines have adopted the convention of using SVC 76 tc do their error 
recording, CP can centralize nearly all error recording. The following 
types of errors are recorded in the error recording area of the VM/370 
system residence pack. 

• ¥H/370 spooling errors 

• VM/370 paging errors 

• I/O errors resulting from user's CMS or RSCS operation 

• I/O error events resulting from a user-initiated diagnostic interface 

• I/O errors or error-related data compiled by an operating system 
running in a virtual machine and interpreted by CP when the operating 
system issued SVC 76 in an attempt to do its own error recording. 

When CP intercepts an SVC 76 issued by an operating system running in 
a virtual machine, it records the error on the VM/370 error recording 
cylinders and passes control back to the virtual machine at the 
instruction following the SVC 76. CP handles SVC 76 in this way only if 
all of the following conditions are met: 

1. All pertinent passed parameters concerning the error record are 
valid for CP»s implementation of error recording. 

2. There can be a resolution of virtual address to real device 
address. 

3. The record type matches a CP-supported type. 

If any of these conditions is not met, VM/370 does not record the 
error on its error recording area; the SVC 76 interruption is reflected 
back to the virtual machine for the virtual machine operating system tc 
do the error recording. Note that the management and processing of SVC 
76 is unaffected by the virtual machine assist and the Extended Control 
Program Support for VM/370 (VM/370 ECPS) on systems supported by VM/370. 
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EBROR RECORDING — VM/370 VERSOS AN OPERATING SYSTEH IN A DEDICATED 
ENVIRONMENT 

An -operating system in a dedicated environment (for example: DCS 
operating standalone in a System/370 Hodel 145) exercises complete 
control over the entire hardware configuration. In the utilization of 
this hardware, there is usually a direct relationship between the 
residence of data and the address used to access this data (device 
address as well as the access location within the device) - Error 
recording, therefore, can be accomplished easily because any data- and 
address-handling schemes used by that operating system can be used to 
create a factual error record. 

Bith VM/370, these operating systems operate under the control of the 
Control Program (CP) component of VM/370. A system resource under DCS 
or OS constitutes real hardware with its real hexadecimal hardware 
address and data records residing at precise locations on that device. 
In most cases, under VM/370 , s control, the following are virtual, net 
real: (1) the device, (2) the data address, and (3) the device type 
parameter used by other control programs operating in the virtual 
machine environment. For example, what DOS considers a 2311 device 
residing at address 214 with certain data at track location 10 could, in 
reality, be a 2314 device with a device address of 310 and a track 
location of 65. 

A virtual 3330, Model 1 mapped onto a real 3330, Model 11 would be 
another example. Other devices, whether or not supported by VM/370, can 
be dedicated to an operating system, in which case VM/370 does not 
translate data addresses or device types. Device address mapping, 
however, may still be dene. 

In 3850 Mass Storage Systems, the 3330V (3330 virtual volume) 
associated with a given CPOID in a MSS application is specified as input 
to the OS/VS Mass Storage Control Table Create Program (GC35-0013) . The 
Mass Table Create creates IODEVICE cards that are used as input to the 
VS system generation procedure. CP's DMKRIO configuration must agree 
with the input to Mass Table Create and the OS system generation 
configuration. This addressing agreement is necessary because CP 
provides the real I/O interface from VS1/VS2 operating systems to MSS 
devices. Operating protocol dictates that in using the ATTACH or DEFUSE 
commands, the virtual address must match the real address (VM/370 
generated addresses) as all errors are reflected to the virtual machine 
for error recovery and the logging process. 

Note: Devices dedicated to a virtual machine's operating system may have 
no address or device translation. These devices may or may not be 
supported by VM/370' s recovery management support (RMS) and errcr 
recording package. 

As stated previously, the operating system in the virtual machine 
not only executes its own I/O error recovery, but can generate its own 
LOGREC data. Keep in mind that these records usually reflect the 
virtual values as VM/370 CP initiates all I/O privileged instructions 
with translated values applicable to the real hardware. As a 
consequence, sense data reflected to the virtual machine because of I/O 
error conditions is associated with a logical device. This virtual 
machine LOGREC data is then of very limited use to the CE since he may 
not know the real device address corresponding to the virtual address 
from which the error was recorded. The SVC 76 interface capability cf 
VM/370 takes care of this problem. 
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SVC 76 

SVC 76 is the supervisor call used by the IBM operating systems to 
record either statistical data or a permanent I/O error incident. 
VM/370 traps a valid SVC 76 event issued by an IEH operating system 
running in a virtual machine environment and captures permanent I/O 
error incidents as well as other specific recording types as explained 
in the following paragraphs. 

The minimum release level of program systems that support SVC 76 is 
as follows: 

VM/370 (running in a virtual machine environment) (Release 2) 

OS/360 (Release 21) 

VS1 

VS2 Release 1 (with single address space) 

VS2 Release 2 (with multiple address spaces) 

DOS Release 27 (with PTF as required) 

DOS/VS 



SVC 76 Handling of I/O Device Errors 

When a valid SVC 76 is issued by an operating system running in a 
virtual machine, VM/370 traps it. VM/370 checks the error recording 
data parameters and the type of error record passed with the SVC 76. If 
invalid, the SVC 76 is reflected to the virtual machine's operating 
system. If valid, VM/370 will: 

1. Translate virtual device addresses found in the record to real 
device addresses. 

2. Record the error in VM/370*s error recording area. 

3. Inform the VM/370 system operator of the I/O error via a console 
message. 

4. Return control to the operating system at the instruction address 
following the SVC 76 instruction, thereby causing the SVC 76 to act 
as a nc-cp instruction as far as the virtual machine is concerned. 

Processing the SVC 76 interrupt in this manner bypasses the error 
recording mechanism of the virtual machine and allows the virtual 
machined job processing to continue after VM/370 gathers the data fcr 
the error recording record. 

Any of the above mentioned operating systems is run standalone, then 
when the SVC 76 is issued in the process of I/O error recovery, SVC 76 
generates an interrupt that signals the operating system supervisor to 
record the error on the operating system's LOGREC data set. 

In either case, as far as job processing is concerned, SIC 76 and I/O 
error recording is not apparent to the user. 
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SIC 76 Handling of Channel Errors 

Channel errors are handled differently from device errors. CP records a 
channel check in ...the s YM/370 error recording area immediately and informs 
the VM/370 system operator of the channel check via a console message 
(bat for a channel data check, no message is issued) . Then CP reflects 
the channel check to the virtual machine. After seeing the error, the 
operating system in the virtual machine issues SVC 76. Since CP has 
already recorded the error, CP ignores the SVC 76 and reflects it to the 
virtual machine (without translating virtual channel and device 
addresses in the error record to real addresses) . The reflected SVC 76 
then causes the operating system in the virtual machine to record the 
channel error in its own LOGREC data set. 



SVC 76 — Parameter Passina 

YM/370 examines the contents of general registers and 1 to determine 
if valid conditions exist for handling the error recording data. 

If the system is OS (Release 21 or above) , VS/1, VS/2, or VM/370 (in 
a virtual environment) then: 

General register = two*s complement of the error record length 
General register 1 = address of the record 

If the system is DOS (Release 27) or DOS/VS then: 

General register = address of the error record minus 8 
General register 1 = Byte 0, Bit must be a 1, 

Bytes 1, 2, and 3 contain the CCB address 

(DOS control block for I/O) 

VM/370 then locates the formatted error record and examines the 
record header for a valid operating system identity (ID) . The record 
type then examined to determine if it is one of the supported recording 
types. 
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Record Modification for VM/370 Error 
Recording 



The error record is Modified, changing virtual inforiation to real. The 
fields aodified vary with the type of record. 

• Type 30, OBR (Outboard Recorder) 

Conmon Fields: 

Primary and Alternate COA are replaced with the real device address 
corresponding to the virtual device address. 

CPUID (CPU lodel number) is replaced with the real machine model 
number. 

JOBID is replaced with the virtual user ID. 

Device Dependent Fields: 

For dedicated DASD devices no modification is required. For 
nondedicated DASD devices, the following modifications are required: 

Seek Address, the relocation factor, found in the VDEVBLOK, adjusts 
the seek address field of the record in order to reflect the true 
real seek address. 

Home Address Read, the relocation factor, found in the VDEVBLOK, 
adjusts the home address read field in order to reflect the true 
real heme address. 

Volume ID, the volume label in the RDEVELOK, replaces the volume ID 
in the record. 

3330, 3340, 3350, and 2305, the relocation factor in the VDEVBLOK, 
adjusts the cylinder address portion of the sense data (sense bytes 
5 and 6) . 

Virtual 23V1 on 2314, the device type is changed to 2314 and sense 
byte 3 is altered to reflect 2314 information. For this situation, 
the 2314 module ID usually found in the sense byte is net 
available. 

Note: The failing CCH and CSW fields are not altered. This results 
in the CCH address in the CSW and data address in the CCW being 
virtual, not real. 

• Type 40, 41, 42, 44, 48, and 4F programming atend records: 

Common Fields: 

CPUID (CPU model number) is replaced with the real machine model 
number. 

JOBID is replaced with the virtual user's IT. 
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• Type 60, DDR (Dynamic Device Reallocation) 

CPDID (CPU model number) is replaced ¥ith the real machine model 
nlimber. 

JOBID is replaced with the virtual user's IE. 

IllMII £UA 2l "f£2l" Device is replaced with the real COA 
corresponding to the virtual device. 

Primary COA 2f "£2" Device is replaced with the real CDA 
corresponding to the virtual device. 

• Type 70, MIH (Missing Interrupt Handler) 

Common Fields; 

CPDID (CPU model number) is replaced with the real machine model 
number. 

JOBID is replaced with the virtual user's ID. 

COA is replaced with the real CDA corresponding to the virtual 
device. 

Primary COA is replaced with the real CDA corresponding to the 
virtual device. 

Device Dependent Fields: 

DASD: For dedicated DASD devices, no modification is required. For 
nondedicated DASD devices, the following modification is required: 

Volume Serial Number is replaced with the volume label from the 
RDEVBLOK. 

• Type 91, MDR (Miscellaneous Data Records) 

Common Fields: 

CPDID (CPD model number) is replaced with the real machine model 
number. 

JOBID is replaced with the virtual user's IE. 

RL1ME1 CDA is replaced with the real COfi corresponding to the 
virtual device. 



U22lJlS3 2i i^e Error Record 

The recording of the error record is accomplished by using existing 
routines in DMKIOC, DMKIOE, and DMKIOF. 
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IZQ £EE£LL Messages 



Id aost cases, CP provides the I/O interface 
initiated I/O activities of virtual machines. 
I/O unit check conditions (OBH 30 error re 
recorded in the VM/370 error recording area. I 
sent to the VM/370 primary system operator in 
unit address cf the device and the userid that 
The same action occurs when a unit check is 
device where SVC 76 is invoked. This message a 
error routines are invoked for recording coun 
statistics fcr various devices, for record 
recording general statistical data in VM/370s er 



to real devices for the 
Therefore, encountered 
cording condition) are 
n addition, a message is 
forming him of the real 
is performing the I/C. 



detected on a dedicated 
lso appears when VM/370 
ter and buffer overflow 
ing demounts, and fcr 
ror recording area. 



I/O Error Recovery -- Detailed Description 



I/O error recovery is attempted for 
CP-supported devices, and for user-ini 
devices through use of the diagnose 
hlocks used for error recovery are 
SDRBLOK, and the IOEBBLOK. In addit 
obtained to generate recovery channel 
first detected by the I/O interrupt ha 
and a sense command is performed to, 
IOERBLOK. The I/O supervisor then exa 
the event was initiated by CP or by a 
a virtual machine event, the I/O inter 
machine. Fcr CP-related I/O errors, 
procedures are invoked. Unit record 
spooling routines; terminal errors are 
routines; and DASD and tape errors are 



CP-initiated I/O operations tc 

tiated operations to CP-supported 

interface. The primary control 

the RBEVELOK, the IOBLOK, the 

ion, auxiliary storage may be 

programs. The initial error is 

ndler. An IOEBBLOK is constructed 

place the sense data into the 

mines the IOBLOK to determine if 

virtual machine. For the case cf 

rupt is reflected to the virtual 

device-dependent error recovery 

errors are handled by the CP 

handled ty the console handling 

handled by other CP routines. 



In attached processor applications, I/O processing and I/O error 
recovery procedures are essentially the same as uniprocessor methods. 
Virtual I/O can occur on either processor, however, the end processing 
of the virtual-to-real CCW string can only be executed on the main 
processor. Only the main processor has real I/O capabilities. 



During an I/O operation, the control 
is in effect. 



block linkage shown in Figure 9 
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Figure 9. I/O Operation Control Block Linkage 
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When channel status word indicators show that an error occurred 
during I/O activity, the I/O interrupt handler constructs an ICERBLCK. 
The I/O supervisor performs a sense command to place the sense data in 
the IOERBLOK, and the error CSW is also placed in the ICERBLQK. When the 
sense -operation is complete, the I/O supervisor invokes the I/O error 
recovery routines for sense data analysis with the control block 
structure shown in Fiaure 10. 
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Figure 10. I/O Error Recovery Control Block Structure for Sense-Byte 
Analysis 



The error recovery procedure analyzes the error and, if recovery is 
possible, builds a recovery CCW string to be executed to attempt 
recovery. In order to preserve the original IOERBLOK, the error 
recovery procedure places the pointer to the IOERBLOK in the RDEVBLOK. 
The error recovery procedure keeps track of the number of retries in the 
I0BRCNT field of the IOBLOK. This count is used to determine if a retry 
limit has been exceeded for a particular error. On initial entry from 

count is zero; and for each retry attempt, the 
error recovery procedure communicates to 
the IOBSTAT and IOBFLAG fields of the 
attempted, the error recovery procedure 
turns on the restart bit in the IOBLFLAG field of the IOBLOK. In 
addition, the ERP bit of the IOBSTAT field in the IOBLOK is turned on to 
indicate to IOS that the error recovery procedure is to receive control 
when the I/O event has completed. This enables the error recovery 
procedure to receive control even if the retry was successful so that 
SER counters can be updated and any storage that was obtained for the 
recovery process can be relinquished, When recovery is attempted, the 
IOBRCAW in the IOBLOK is set to point to the recover? CCW string and 
control is returned to the I/O supervisor with the control block linkage 
as shown in Figure 11. 



the I/O supervisor, the 
count is increased by one. The 
the I/O supervisor by way of 
IOBLOK. When retry is to be 
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Figure 11. Control Block Linkage for Retry 



If the retry attempt is successful, control is still returned to the 
error recovery procedure. The ERP flag bit in the IOBLOK determines 
this. 

If another unit check occurs on the retry attempt, the I/O supervisor 
will follow the same procedure as the initial error sequence by building 
an IOERBLOK and performing a sense command. When the I/O error 
recording routine returns control to the I/O supervisor, the ERP hit of 
the IOBSTAT flag in the IOBLOK being set causes control to be returned 
to the ERP. 

The error recovery procedure notes that this is a retried operation 
(ERP flag and IOBRCNT field nonzero) . If the recovery procedure retries 
the operation, the restart procedure is again followed with the lOBRCHT 
value increased by one. The IOERBLOK and recovery CCWs associated with 
the unsuccessful recovery attempt are purged by returning the storage to 
the system. (Remember that the original IOERBLOK is being saved by 
placing a pointer to it in the RDEVBLOK.) It can be seen that the error 
recovery procedure, not the I/O supervisor, is the routine controlling 
recovery attempts and determining when an error is a permanent one. The 
SDR counters are updated using the sense information from the original 
IOERBLOK. Figure 12 shows the control block relationship while updating 
the SDR counters. The repetitive correction cycle is followed until 
recovery is accomplished or the error recovery procedure determines 
(from the retry count, IOBRCNT) that the error is permanent. If the 
specified number of retries fails to correct the error, the fatal flag 
(permanent error) in the IOBLOK is turned on (IOBSTAT=IOBFATAL) and 
control is returned to the I/O supervisor. The I/O supervisor will call 
the I/O error recording routine. The I/O error recording routine 
analyzes the sense data to determine if a recording condition exists, if 
so, an I/O error formatted record is constructed and the record is 
queued to be written out in the I/O error recording area of the VH/370 
system residence device. If the user of the virtual machine has 
privilege class F, the I/O error recording routine tests flags in the 
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RDEVBLOK to determine if intensive recording node is in effect for this 
device. If the conditions are met, an I/O error record is created. 
This record is constructed and recorded as described previously. 
Control is returned to the I/O supervisor, which reflects the error to 
the user of the I/O operation. 
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Figure 12. Control Block Relationship for SDR Counter Update 



Section 3. Error Handling 47 



I/O Error Recording and Error Recording Area 



The error recording facilities of VM/370 format and record outboard 
error records, and record formatted machine check and channel check 
records created by the RMS routines of VM/370. 

The error recording routines of VM/370 do not actually perform I/O 
operations. Instead, the I/O error routines treat the error recording 
area allocated on the VM/370 system residence pack as a logical 
extension of VM/370 storage. These extensions of VM/370 storage are in 
the form of logical pages that can be read and written out of by the 
paging supervisor of VM/370. The error recording routines place 
multiple error records within a page; when an error record is assembled 
within a page, a pointer is updated to indicate the beginning of any 
unused area. The next error record is checked to see if it can be 
contained in the remainder of this page. If it can, the error record is 
read into the page and the pointer is updated to again reflect any 
residual storage available for the next error record. This process 
continues until an error record is encountered that cannot be contained 
within the page. When this happens, the page is scheduled to be read 
out to the next available slot in the error recording area and a new 
page in storage is assigned to accept and retain the error record. The 
process continues in like manner. 

The error recording area is from two to nine adjacent cylinders 
assigned on the system residence volume. The starting cylinder number 
and number of cylinders are specified in VM/37C generation procedures. 
When the error recording area is 90% full, and again when 100% full, the 
I/O error routines instruct the VM/370 system operator to invoke the 
CPEREP command to print (or create a tape of) the error data and erase 
the recording area. Errors are recorded in the order of occurrence 
until the allotted space is exhausted. 

With the support provided for the 3031, 3032, and 3033 processors, 
CPEREP need net be aware of the content or the EC level of the processor 
logouts in order to format machine check and channel check records. 
Format and content information is provided via the SRI (Service Record 
File) device. Frames (records containing text and scan buffer codes) 
are maintained on the SRF device by customer engineering, and software 
makes use of these frames to interpret and format inboard errors. 
Whenever the VM/370 error recording cylinders are formatted on a 3031, 
3032 or 3033 processor, the SRF is accessed and the frames are 
retrieved, formatted as frame records, and recorded at the beginning cf 
the VM/370 error recording area by the process described above. When 
CPEREP is invoked, these frame records are used to format MCH and CCH 
records for the printed report. 

The SRF device is accessed by VM/370 to read frame data (a) during 
VM/370 system initialization if the error recording cylinders have net 
been previously formatted; and (b) as a result of running CPEREP with 
the CLEARF operand. To ensure that the VM/370 control program has 
access to the SRF device, the following steps should be followed to 
activate the SRF: 

1. Check that the I/O interface for the service support console is 
enabled. 

2. obtain the configuration frame on the service support console. 

3. The SRF appears disabled until accessed on the 3032. Activate the 
SRF on the 3031 and 3033 by selecting SRF mode A2. 
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it. VARY ON cuu (SBF address) on the operator's console. 

5. ATTACH cuu * cuu to attach the SRF device to the operator's 
console; or ATTACH cuu userid cuu to attach the SEF device to the 
console cf the class F user who runs CPEREP. 

In a 303x environment, access to the SRF device by an SCP in a 
virtual machine must be considered when planning to run EREP to print 
the error log belonging to that virtual machine. The SRF device must be 
accessible to the operating system in a virtual machine when it 
initializes its error log in order that frame data may be read from the 
SRF. The VM/370 system operator should attach the SRF device to the 
virtual machine before that SCP initializes its error log (for example, 
in the case cf OS/VS2, before running IFCEIPQC) ; the virtual machine 
operator should then vary the SRF online. 

The error recording facilities of VM/370 are of the following types: 
OUTBOARD BICORDING: 

• Statistical data recording 

• Permanent I/O errors 

• Environmental data records 

• Intensive mode recordings 

• Specific DASD recording requirements 

• Specific tape recording requirements 

• Software abend records 

INBOARD RECORDING: 

• Machine checks 

• Channel checks 



I/O Statistical Data Recording (SDR) 

Statistical data recording is the accumulation and the recording of I/O 
error statistics that relate to specific devices. VM/370 supports SDR 
recording for CP- initiated I/O events by building and maintaining device 
statistics tables (counters) in the SDRBLOK associated with the I/O 
device. These counters are updated when a device-dependent error 
recovery procedure (ERP) determines that the error has either been 
corrected successfully or is a permanent error. SER counters are 
updated based on the sense information in the original IOERBLOK. The 
updating of the counters is done asynchronously. If the update function 
causes a counter overflow, a short OBR record is built. The OBR record 
is then placed on the asynchronous output queue. This causes the OER 
record to be written on the error recording area asynchronously. 

When the SHUTDOWN command or NETWORK SHUTDOWN command is issued by 
the system operator, any devices that have SDR counters associated with 
them cause control to be passed to the I/O error recording routine to 
format a short OBR record. (A long OBR is formatted for 3400 tapes.) 

The VARY OFFLINE command or NETWORK VARY OFFLINE command of a device 

that has associated SDR counters also causes control to be passed to the 

I/O error recording routine to format a short OER record (a long OBR is 
formatted for 3400 tapes) . 

The VARY OFFLINE, SHUTDOWN, NETWORK VARY OFFLINE, and NETWORK 
SHUTDOWN commands result in an OBR record being written to the error 
recording area synchronously. 
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Permanent I/O Error Recording 



Permanent I/O errors related to VM/370-initiated I/O events are recorded 
by the I/O error recording routines of VM/370- When a device-dependent 
error recovery procedure determines that an I/O event cannot be 
successfully recovered, the fatal flag is turned on in the IOBLOK and 
control is returned to the I/O supervisor. The I/O supervisor invokes 
the I/O error recording routines with the control block structure as 
shown in Figure 13. The I/O error recording routines format the error 
and record it on the error recording area. 
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Figure 13. Control Block Linkage — Fatal Error Condition 



Environmental Data Recording 

When the I/O supervisor receives a unit check interruption from a 3330, 
33*10, 3350, or 2305, the error recovery procedure is invoked. If the 
sense information indicates that an environmental data recording is 
required, the error recovery procedure builds the necessary channel 
program to retrieve the error log data from the file control unit. 

The sense data that indicates this condition is as follows: 



Machine 
2305 


Sense Byte 
2 


Bit 



Condition 
Buffer Log Full 


3330,3340,3350 


2 


3 


Environmental Data 



The manner in which the error recovery procedure passes the data to 
the i/o error recording routine differs between the 2305 and the 
3330/3340/3350 as shown in Figures 14 and 15, respectively. 
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Figure 14. 2305 Control Block Structure — Environmental Data Recording 

The IOEREXT field in the IOERBLOK contains the length in doufclewords 
of the extended data area. The I/O error recording routine builds an 
environmental data record in the proper format, queues the request fcr 
recording, and returns to the I/O supervisor. The EASE error recovery 
procedure retries the operation and normal processing ccntinues. 

A different control block linkage exists on 3330/3340/3350 
environmental data recordings due to the amount of data. The DASD errcr 
recovery procedure builds multiple IOERBLOKS and chains them together to 
pass the data to the I/O error recording routines. 
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Figure 15- 3330/3340/3350 Control Block Structure — Environnental 
Data Recording 

The IOERLOC pointer in the IOERBLOK points to the next IOERBLOK en 
the string- The error recovery procedures obtain free storage and 
construct IOERBLOKs to be placed on the string until the buffer on the 
control unit is completely unloaded. The I/O error recording routine 
builds an environmental data record in the proper format, queues the 
request for recording, and returns to the I/O supervisor. The error 
recovery procedure retries the operation and normal processing 
continues. 



Intensive Mode Recordings 



On any unit check occurrence the I/O supervisor invokes the I/O error 
recording routines to determine if the conditions for intensive mode 
recording are satisfied- Intensive mode is an error recording mode 
whereby errors are recorded for a specific device that achieves a unit 
check condition and sense data that matches previously defined sense 
data values. The SET RECORD command starts intensive mode. If 
intensive mode recording conditions are satisfied, an I/O error record 
is constructed, formatted, and recorded in the I/O error area of the 
VM/370 system residence device, and a flag is set in the IOERBLOK to 
indicate that the error has been recorded (I0ERFLG2 = IOERCEMD) . This 
recording is done for CP-owned devices as well as dedicated devices 
attached to virtual machines. The user who initiated the intensive mode 
operation must run the CPEREP program to retrieve the records created 
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while this option was active. No messages occur to inform either the 
YH/370 system operator, or the virtual machine user when a recording is 
made or when intensive mode is disabled by the I/O error recording 
routines after the tenth recording- Intensive mode (SET BECOBD option) 
can be inveked enly on o^e real hardware device at any time and only by 
a user with the privilege class F command usage. 

Hote: For the privilege class F virtual machine all normal error 
recording is suspended except for the 'intensive mode' selected device. 
If however, the F class user invokes SVC 76 to pass a record to CP to 
record, CP will honor such a request. 



VM/370 I/O Error Recordings 

OBB records are written if any of the following conditions exist for all 
but the privilege class F user (unless intensive mode is specified for a 
particular device) . 

An unrecoverable (permanent) I/O error which was initiated as a 
VM/370 I/O task (CP request) . 

Counter overflow statistics (SDR count) . 

SHUTDOWN and NETWORK SHUTDOWN commands (devices with SDR counters) . 

VARY OFFLINE (devices with SDR counters) . 

2305/3330/3340/3350 — Equipment Check. 

2305/3330/3340/3350 — Busout Check. 

2305/3330/3340/3350 — MDR record on BUFFEB UNLOAD command (X«A4* cr 
X'24 1 ) to a nondedicated DASD storage device by a virtual machine. 

3340 — Seek Check. 

2305/3340/3350— Data Check. 

2305/3330/3340/3350 — Overrun. 



Error Recording Record Layout 

Error recordings vary in length and format depending on the malfunction 
or the device encountered. Data that relates to channel check, machine 
check, or unit check conditions is arranged in byte-formatted records in 
the error recording area. Figures 16, 17„ 18, 19, and 20 describe the 
layout and data length of the fields within defined record types. Use 
Figure 21 with these charts to ascertain the origin of particular fields 
of data. 

The paired alphabetical characters shown in the fields of Figures 16, 
17, 18, 19, and 20 correspond to the location cedes in Figure 21. The 
location code in conjunction with the type of error (HC, UC, CC) 
indicates the availability of that data and what data clock or function 
contains cr generates this data. 
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Figures 22 and 23, using the same paired alphabetical character 
scheie, describe the 24-byte header that precedes the error record. 
Figure 23 describes the contents and source of the fields indicated in 
Figure 22. 

For additional information on error record layout as used by the CP 
component of VM/370 refer to VM/370 Data Areas and Control Block Lpjjic. 
For information on the printout format of supported~error record types, 
refer to the OS/VS. DOS/VSE. VM/370 Environmental Recording Editing and 
Printing (IREP) Program. Support logic for this~program is contained~"in 
the 0S7ys # ~D0S/ySE, VM/370 Environmental Recording Editing and Printing 
(FREP) Program Logic. 
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Header Record 



24 Bytes 



AA 



Job ID 



u uytes 



Failing CCW 



8 Bytes 



AJ 



CSW Stored 8 Bytes 

When error was detected 



AK 



Device Depletion 
Count cf Double- 
Word Size 
1 byte BD 



SDR Work Area 
Count 



Channel S Unit Address | Device Type 

of Failing Device | Characteristic 

I 
(SEC) 3 bytes AD | 4 bytes AN 



! 



Channel 8 Unit Address! Retry (Sense Byte 
Physical location of j Count j Count 
Failing Spindle (PRI) | 2 Ey tes | 2 Bytes 



1 byte BE | 3 bytes AM 


I *Q I 


BF 


Volume ID Associated With I/O Error 


6 bytes 


AR 


Last Seek Address of DASD 


8 bytes 


AS 



Actual Hone Address Read 



6 bytes 



AT 



SDR Work Area (RDEVCNTS) variable length 



BH 



Sense Data variable length 

Physical identity of device when available 



AD 



Figure 16. Unit Check Record Layout (Long) 



r 

I Header Record 


24 bytes 


AA 


— T 


I Device Dependent Data 


variable length 


BG 


1 



Figure 17. Nonstandard Record Layout 



Header Record 24 bytes 



AA 



Device Type | SDR Work Area | Channel and Unit Address 

Characteristic | Count | of Failing Device 
4 bytes AN | 2 byte BE | 3 Bytes AD 



SDR Work Area 

Variable Length 



BH 



Figure 18- Unit Check Record Layout (Short) 
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Header 24 Bytes 




AA 


i 




Program Identity 8 Bytes 




AB 






Job Identity 8 Bytes 




AC 






Machine Check Old PSW 8 Bytes 




AE 






Machine Independent Logout 
280 Bytes 




AF 






Machine Dependent Logout 
(Extended Logout) variable len 


gth 


AG 






Damage Assessment 
80 Bytes 
Identifies the Extent of Damage 
by a Recovery Management Pro 


Pound 
gram 
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Figure 19. Machine Check Record Layout 



Header 



24 Bytes 



AA 



Job ID 



8 Bytes 



AC 



Active I/O Units 16 Bytes AI 

Contains up to eight devices on failing channel 



Failing CCW 8 Bytes 


AJ 


CSW Stored ¥hen Error Detected 8 Bytes 


AK 


Extended Channel Status | 




Word AL | Device Type 


AN 


4 Bytes | 4 Bytes 

i 




i 

I Channel S Unit I Multiprocessing 




Channel ID | Address | Information 


AW 


1 Byte | 3 Bytes |Fail-| Re- | CP0-1 


CPO-2 


I ling Iserved IChannel 


Channel 


I |CPD | for | 




I land | IBM | 




I | Stat— | use I 




I | us | | 




AO AM 1Byte iByte 1 Byte 


1 Byte 



Channel Logout 

Variable Length 

Reflects the Internal Hardware Status of 
the Failing Channel at I/O Interrupt Time 



AP 



Figure 20- Channel Check Record Layout 
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Location 
Code 



AA 
AB 
AC 

AD 
AE 
AF 

AG 
AH 
AI 

AJ 
AK 
AL 

AH 

AN 
AO 
AP 
AQ 
AR 
AS 

AT 
AD 
AV 
AW 
AX 
AY 
AZ 
6A 
BB 
BC 
BD 

BE 

BF 
B6 
BH 



Header 



MC 



DC 



DC 
Short 



CC 



Non 
Std 



Data Recorded 



Chart 

Program IE 

Job ID (DSERID) 

Channel S Dnit 

Mach Ck Old PSW 

Mach Ck Independent 

Logout 
CPD Hardware Logout 
Damage Assessment 
Active I/O Dnits on 

Channel 
Failing CCW 
CSW 

Extended CSW 
Physical Spindle or 

Channel 8 Dnit 
Device Type 
Channel IB 
Channel Logout 
I/O Retries 
Volume ID 
Last Seek Sddress 

Actual Home Address 
Sense Data 
NA 
Multiprocessing 



Device— Dependent 

Data Count 
Statistical Data 

Work Count 
Sense Eyte Count 
Device— Dependent 
Stat. Data Ctrs 



Froi 



NA 

VMBLOK 
RDEVBLOK 
MCH Buffer 

HCH Buffer 
MCH Buffer 
NA 

CCH 

IOBLOK 

IOERBLOK 

CCH 

IOERBLOK 

IOBLOK 

RDEVBLOK 

RCHBLOK 

CCH 

IOBLOK 

RDEVBLOK 

IOBLOK 

IOERBLOK 

IOERBLOK 

IOERBLOK 

NA 



IOERBLOK 



Recorder 
IOERBLOK 

SDRBLOK 



L e 3 e n d : 

MC = Machine Check 

DC = Dnit Check 

CC = Channel Check 

Non Std = Nonstandard 



CCH = Channel Check Handler 
MCH = Machine Check Handler 
NA = Not Applicable 



Figure 21. Record Breakdown Table (Except Header) 
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Bits 



RECORD HEADER - 24 BYTES 



8 



16 



24 



32 



40 



48 



56 



63 



Record | Operating I Switches |Re- | Record | Re- 
Type I System | Independent— Dependent j served j Count j served 
I Ibyte byte 1 byte 2|for IEM| I for IBM 



I use 



j \~u 



1 byte | 1 byte | 



3 bytes 



I I I 

|1 byte | 1 byte |1 byte 



Date and Time CE 
8 bytes 



Ver- | 
sion I 
No. CF| 
I 
1 byte | 



CPO Serial 
Nuiber 
CF 

3 bytes 



CPU Model 
Number 
CG 

2 bytes 



MAX HCEL 

Length 

CG 

2 bytes 



Figure 22. Layout of the Header Portion of the Error Records (24 Bytes) 
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| Record Header Field 
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I Record 
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jFrom calling routines 










or type of entry 


CA | 


1 Qrierat 


ing System 


System description 


CB | 








module 




1 5 w itches { dep e n&en t/ i n depende n t } 




CC 1 


illte 











I Bit 





Multiple Record Recording 


NA 






1 


NS Machine 


Always (using NS 
Clock Binary) 






2 


EC Mode 


PSW 






3 


Reserved for IBM Dse 


— 






4 


Time Macro Used (HHMMSS) 


Always 1 




IBjte 


1 


MACHINE CHECK 






I Bit 





Short Form 


NA 






1 


Record Incomplete 


NA 






2 


System Terminated 


MCH 






3 


First Record of two 


NA 






4 


Channel Record Included 


NA 






5 


Data Overlaid 


NA 






6 


External Machine Check 


NA 




Illte 


1 


CHANNEL CHECK 






I Bit 





Operator Message 


NA 






1 


Record Incomplete 


NA 






2 


System Terminated 


CCH 






3 


Channel unsupported 
or failed to log. 


CCH 






4 


Invalid COA 


CCH 






5 


Data Overlaid 


CCH 






6 


ERP in Progress 


NA 




I Byte 


1 


UNIT CHECK 






I Bit 





SDR dump (EOD) 


RECORDER 






1 


Temporary error 


IOBLOK 






2 


Short record 


RECORDER 






3 


MP system 


NA 






4 


CPU B 


NA 






5 


Volume dismount 


NA 






6 


SVC reguested 


NA 




Illte 


2 


MISCELLANEOUS DATA 

Recorder (Nonstandard) 
Record ID Code 

01 = 3330 | 

02 = 2305-2 | 

03 = 3270 | 

04 = 3211 | 

05 = 3705 

08 = 2715 | 

09 = 3340 | 
0A = 3330-11 

11 = 3350 I 

12 = 2305-1 | 
FF = Reserved for IBM Use ] 






j Record 


Count i 


Always 01 ! 


CE | 


IDate 


S 


Time | 


RECORDER | 


CE | 


|CPD ID 


and Serial I 


Store CPU ID 1 


DF j 


|Hax HCEL Length 1 


Store CPD ID I 


CG | 


I Version Number \ 


Store CPD ID | 


CF | 


|NA = 


Not Available | 


1 





Figure 23. Header Record Table 



Section 3. Error Handling 59 



VM/370 Recovery Features -- Introduction 

The primary objectives of VM/370's recovery management support are: 

• To reduce the number of system terminations that result from machine 
malfunctions. 

• To minimize the impact of such incidents. 

The programmed recovery, which accomplishes these objectives, allows 
system operations to continue whenever possible, and records the system 
status for all errors. The HCH (Machine Check Handler) and CCH (Channel 
Check Handler) provide the recovery management functions of VH/370. 



MACHINE CHECK HANDLER 

A machine malfunction can originate from a processor, processor storage, 
control storage, or a channel group. When any one of these fails to 
work properly, the hardware tries to correct the malfunction. If the 
machine recovers from the error through its own recovery facilities, a 
machine check interruption notifies the appropriate machine check 
handler routine. The machine check handler records the fact that the 
machine operated improperly. Concurrently with the machine check 
interruption, the processor logs out fields of information in processor 
storage. This information describes the cause and nature of the error. 
MCH analyzes this information and builds the machine check record. 

If the machine fails to recover from the error through its own 
recovery facilities, a machine check interruption occurs, and an 
interruption code indicates that the recovery attempt failed. The 
machine check handler then analyzes the data and tries to keep the 
system as fully operational as possible. The cause of the malfunction 
determines what action the machine check handler takes: 

• Resume operations, leaving no adverse effects on the system. 

• Resume system operations by terminating the virtual machine that was 
interrupted. 

• Isolate the failure to a page and flag the page as invalid or 
unavailable for use by the paging supervisor. 

• Place the system in a disabled wait state. 

• If the 158 AP or 168 AP operating in attached processor mode had an 
unrecoverable malfunction occur on the attached processor in problem 
program state, resume operations in uniprocessor mode. 



CHANNEL CHECK HANDLER (CCH) 

The channel check handler is a resident program that receives control 
from the I/O supervisor when a real channel error occurs. CCH records 
the error. CCH reflects channel control checks, channel data checks, 
interface control checks, and channel interface inoperative (for a 
dedicated channel) to the virtual machine to allow the SCP in that 
virtual machine to attempt recovery, and/or initiate appropriate 
termination procedures. If CCH determines that system integrity has net 
been damaged, channel errors associated with an input/output operation 
initiated by CP (for example, paging or spooling) are retried by the 
appropriate device-dependent error recovery procedure. 
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If CCH determines that system integrity has teen damaged (fcr 
example, if the channel has been reset, or if the device address stored 
is invalid) , CCH places the system in a disabled wait state and sends a 
message to the VM/370 primary system operator. For the 4331 and 4341 
processors, limited channel logout is still available, but no fixed cr 



! I/O extended lonont area exists. 



HAMU.LJ.Hfc uf naKD naCHINE CHECKS 



If a permanent error (hard machine check) occurs on the main processor 
(or attached processor) , the error is analyzed to determine whether cr 
not it is correctable by programming. Time-of-day clock and timer errors 
that result in a machine check interruption that are not correctable and 
cannot be circumvented place the real computing system in a disabled 
wait state. 

Uncorrectable or unretryable processor errors, storage errors, and 
storage protect key failures are handled as discussed in the following 
paragraphs. 



Processor Errors 



When a machine check interruption indicates that a processor error 
associated with VH/370 cannot be corrected cr retried the system 
operator is informed of the error and the system is put in a disabled 
wait state.. All virtual machine users must log on again. If the error 
is associated with a virtual machine, the user is informed of the errcr 
and the virtual machine is reset, unless it is using the virtual=real 
option. In that case, the virtual machine is terminated, and the user 
must then log on and reinitialize (via IPL) his machine. 

If VH/370 is being run in attached processor mode and an 
uncorrectable error is encountered on the attached processor while 
executing in problem program state, system operation continues in 
uniprocessor mode on the main processor. 



Storage Errors in a Virtual Machine Page 



When the control program (CP) detects a permanent storage error (hard 
machine check) in a real storage page frame that is being used by a 
virtual machine, the frame is marked invalid if the error is 
intermittent, or unavailable if the error is solid. If the page frame 
has not been altered by the virtual machine, a new page frame is 
assigned to the virtual machine and a backup copy of the page is brought 
in the next time the page is referenced. ill storage errors are 
transparent to the virtual machine user,. 

If the page frame has been altered, VH/370 resets the virtual 
machine, clears its virtual storage to zeros, and sends an appropriate 
message to the user. If the virtual machine is using the virtual=real 
option, it is terminated. in either case, normal system operation 
continues for all other users. 
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Storacje Errors in the CP Nucleus 

Multiple-bit storage errors in the CP nucleus cannot be corrected; they 
cause VM/370 to terminate. (Single-bit storage errors are corrected by 
ECC, as noted above.) 



Storage Protect Key. Failures 

When intermittent storage protect key failures occur, whether associated 
with VM/370 or a virtual machine, the key is corrected and operation 
continues. 

If the storage protect key error is uncorrectable (solid) and is 
associated with a virtual machine, the user is notified and the virtual 
machine is terminated. The page frame is marked unavailable. 
Uncorrectable storage protect key failures associated with VM/370 cause 
the VM/370 system to be terminated. An automatic restart reinitializes 
VM/370. 



HANDLING OF SOFT MACHINE CHECKS 

Although hard machine checks always cause a machine check interruption 
to occur and logouts to be written, soft machine checks are handled in 
one of two operating modes — recording mode or quiet mcde. 

• In recording mode, soft machine checks cause machine check 
interruptions and write logouts. 

• In quiet mode, only hard machine checks cause machine check 
interruptions and write logouts. 

The normal operating state of VM/370 for CPU retry reporting is 
recording mcde. For ECC (error checking and correction) reporting, the 
initialized (normal) state of VM/370 is model-dependent: quiet mode for 
all VM/370-supported processors except Models 155II and the 165II. The 
initial state for the 155II and 165II is record mode. 

A change from recording mode to quiet mode can occur in one of two 
ways: when 12 soft machine checks have occurred, or when the SET HOLE 
BETRY/MAIN QUIET command is executed by maintenance personnel. 

To revert to record mode again, the command SET MODE RETRY/BAIN 
RECORD must be issued. 

In attached processor applications, soft error recording can be set 
or reset for the selected processor if so desired. 

If a soft machine check (a transient error) occurs while the system 
is in recording mode, a machine check record containing information 
about the error is written on the error recording cylinders. This 
record includes the data in the fixed logout area, the date, the time cf 
day, and other pertinent data. The operator is not informed that a soft 
machine check has occurred. 

If a transient error occurs while the system is in quiet mode, no 
machine check interruption occurs, and no logouts are written. The 
hardware, which had gained control when the soft machine check occurred, 
returns control to either VM/370 or the problem program, depending en 
which had control at the time the machine check occurred. 
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Multiple-bit ECC storage errors that occur en a 3031, 3032 or 3033 
processor are not recorded as soft errors, but rather as solid errors* 
If the storage frame that incurred the error is assigned to a virtual 
machine, it is removed from system use without any attempt to determine 
whether the error is intermittent. The SET MODE HUH command is treated 
as invalid en these processors. 

ERROR RECOVERY PROCEDURES 

VM/370 includes device-dependent error recovery procedures for all 
devices supported by VM/370. Functionally, these procedures perform as 
their counterparts do in an OS or DOS system. VH/370 uses the standards 
used by OS cr DOS for priority of error testing, recommended retry 
action, and number of retry attempts for a particular error type. The 
error recovery procedures accept and use the extended channel status 
word, determine if retry is possible, and start retry actions. 

CP In^ut 'Output Errors 

An appropriate error recovery procedure is invoiced whenever an error 

occurs that is related to a CP input/output operation, such as paging or 

spooling. If VM/370 cannot correct the error, VH/370 records the error 
and notifies the system resource operator of the error. 

Handling of Virtual Machine Input/Output Errors 

VM/370 passes input/output errors associated with virtual machine START 
I/O requests to the virtual machine. The machine operating system 
assesses the error and attempts retry. 

Note that CMS uses the DIAGNOSE interface to request VM/370 to 
perform input/output operations, and VM/370 then performs any necessary 
recovery operations for errors associated with the request. 

Recording Virtual Machine In£ut/Out£ut Errors 

By use of the SVC 76 error recording interface, VM/370 provides uniform 
recording of errors encountered by operating systems running in virtual 
machines. VM/370 records the real address (rather than the virtual 
address) of a device that has an error, to allow it to be located by 
support personnel. The operating systems that use the SVC 76 interface 
are: 

VM/370 Release 2 and above 

(running in a virtual machine) 
DOS/VS 
OS/VS1 
OS/VS2 

OS Release 21.0 and above 
DOS Release 27.0 (requires PTF #1124) 
DOS Release 27.1 (requires PTF #2051) 

When an SVC 76 is issued, CP examines the error record built by the 
virtual machine operating system. If the information is valid, CP 
translates from virtual to real device addresses and then records If 
this information is invalid, CP reflects the SVC to the virtual machine 
and no recording takes place. Duplicate recording of errors is thus 
avoided. 



Section 3. Error Handling 63 



In case cf a permanent I/O error, VM/370 sends a message to the 
primary system operator. 

If a virtual machine is using one of the above operating systems and 
is also using the virtual machine assist feature, then all SVCs are 
handled by the assist feature (except SVC 76, which is always handled by 
CP) . However, the user can specify that CP handle all SVCs by issuing 
SET ASSIST NOSVC, or by including the SVCOFF option in his directory 
entry. 

If a virtual machine is using an operating system that does not use 
the SVC 76 interface, both CP and the virtual machine record errors, but 



RECORDING FACILITIES 

The OS/VS environmental recording, editing, and printing program (EREF) 
is executed when the CMS CPEREP command is invoked. The output produced 
by the command is determined by information contained in the VM/370 
error recording area and/or SYS1.LOGREC data on tape and the supplied 
CPEREP operands. The printed output from CPEREP under VM/370 has the 
same format as that generated by OS/VS EREP. The system can: 

• Edit and print all or specific error records contained in the system 
error recording area or tape history file 

• Create a history of records on an accumulation tape 

• Erase the error recording area and, optionally, the SRF frame records 
on a 3031, 3032 or 3033 processor 

For additional information on OS/VS EREP and the CPEREP command, a 
tool for software and hardware problem analysis, see Section 4. 



VM/370 Repair Facilities 



The Online Test Standalone Executive Program (OLTSEP) and online tests 
(OLT) execute in a virtual machine that runs concurrently with normal 
system operations. These programs provide online diagnosis cf 
input/output errors for most devices that attach to the IBM System/370. 

The service representative can execute online tests from a terminal 
as a user of the system; VM/370 console functions, including the 
ability to display or alter the virtual machine storage, are available 
when these tests are run. Those tests that violate VM/370 restrictions 
may not run correctly in a virtual machine environment. 



VM/370 Restart Facilities 

When either MCH or CCH determines that an error has damaged the 
integrity of VM/370 the system is placed in a disabled wait state. On a 
subsequent reloading of VM/370, the system operator can elect to execute 
a warm start, thus allowing terminal lines to be re-enabled 
automatically and completed spool files to be maintained. Storage 
reconfiguration data (such as page frames marked unavailable or invalid) 
that is acquired during the process of recovering from real storage 
errors is lest. After a VM/370 system failure, each user must 
reinitialize his virtual machine. 
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The same philosophy of malfunction handling is evident in Models 158 
and 168 operations in attached processor mode. However, if error 
analysis determines that a nonrecoverable fault is associated with the 
attached processor while it was running in problem state, the system 
continues operating in uniprocessor mode on the main processor. In 
addition, virtual machines associated with the attached processor 
(AFFINITY option set to the attached processor) are set for execution en 
the main processor.. ... £iich._vir_tual Jiachines are notified of system action 
and their virtual machine consoles are placed in console function mode. 

Resetting of a virtual machine, whether caused by a real computing 
system malfunction or by a virtual machine program error, does net 
affect the execution of other virtual machines, unless they are sharing 
the area in which the malfunction occurred. 
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Hardware Errors and Recovery Management 
Support 



The System/370 systems supported by VM/370 have built-in error detection 
logic in the processor, channels, and main storage- This detection 
logic, working with additional hardware logic, allows the system to 
attempt the correction of certain error conditions. When errors are 
correctable, they are referred to as soft errors and have no adverse 
effect on VM/370. They are also usually not apparent to the virtual 
machine's operating system. 

The following errors are not corrected by the system: channel control 
checks, channel data checks, and interface control checks for user 
SlO-initiated channel programs; and channel interface inoperative on a 
dedicated channel for user SlO-initiated I/O. These errors are 
reflected to the virtual machine. 

When errors are not correctable, hardware-initiated machine check 
interruptions invoke the Recovery Management Support (RMS) of VM/370. 
RMS is part of the VM/370 Control Program, and is provided on all 
processors supported by VM/370 and on their supported channels. 

The two primary objectives of RMS are (1) to reduce the number cf 
system terminations that result from machine malfunctions and (2) to 
minimize the impact of such incidents when they occur (see Figure 24) . 
These objectives are accomplished by programmed recovery to allow system 
operations to continue whenever possible and by the recording of system 
status for both transient (corrected) and permanent (uncorrected) 
hardware errors. 



r , 

I | I System 
I j I Program 
I Function | Explanation | Module 


I Machine |To record all machine checks and recover from | DMKMCH 1 
I Check | hard machine checks, or to reset or terminate | DMKMCT 2 
I Handler | virtual machines or terminate System/370 | 
| | operations or if attached processor mode change | 
I | to uniprocessor operations when necessary. | 


1 Channel |Tc record channel checks and effect proper | DHKCCH 
I Check j recovery or terminate System/370 operations | 
I Handler j when necessary. I 


jifloth the machine check and channel check modules, where pertinent and 
I possible, post messages to the primary system operator informing him 
I of the status of the system. 

I 2 Machine check handler operations exclusive to attached processor mode 
I termination situations, malfunction alerts, and automatic processor 
| recovery are contained in the module DMKMCT. 



Figure 24. Summary of RMS Functions 



Machine Check Handler—An Overview 



A machine malfunction can originate in the processor, main storage, cr 
control storage. When any of these fails to work properly, an attempt 
is made by the machine to correct the malfunction. Whenever the 
malfunction is corrected, the machine check handler is notified by a 
machine check interruption. The machine check handler records the fact 
that the machine has failed to operate properly. Concurrently with the 
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machine check interruption, the processor logs out fields of inforiaticn 
in main storage detailing the cause and nature of the error. The model 
independent data is stored in the fixed logout area and the model 
dependent data is stored in the extended logout area. The machine check 
handler uses these fields to analyze the error and to produce the error 
report. 

If the machine fails to recover from the error through its own 
recovery facilities, a machine check interruption occurs, and the fixed 
logout contains an interruption code that indicates the recovery attempt 
was unsuccessful. The machine check handler then analyzes the data and 
attempts to keep the system as fully operational as possible. The cause 
of the malfunction determines what actions MCH takes: 

• Resume operations leaving no adverse effects en the system. 

• Resume system operations by terminating the user that was 
interrupted, 

• Isolate the failure to a page and flag the page as invalid or 
unavailable for use by the paging supervisor.. 

• Place the system in a disabled wait state. 

• In VM/370 attached processor operations, processing may continue in 
uniprocessor mode if the attached processor malfunctions while in 
problem program state and recovery is not possible. 

Note: Loss of system integrity prevents the recording of hard machine 

checks in the supervisor (CP) . Error information of this type may be 

obtained through the use of the processor's hard stop facility if the 
machine check is repetitive. 

LEVELS OF ERROR RECOVERY 

Recovery from machine malfunctions can be divided into the following 
categories: functional recovery, system recovery, operator-initiated 
restart, and system repair. These levels of error recovery are 
discussed in order from the easiest type of recovery to the most 
difficult. 

Functional Recovery 

Junctional recovery is recovery from a machine check without adverse 
effect on the system or the interrupted user. This type of recovery can 
be made by either the processor retry or the ECC facility, or the 
machine check handler. The processor retry and ECC error correcting 
facilities are discussed separately in this section since they are 
significant in the total error recovery scheme. Functional recovery by 
the machine check handler is made by correcting Storage Protect Feature 
(SPF) keys and intermittent errors in main storage. 



.§I§1:em Recovery 

System recovery is attempted when functional recovery is impossible. 
System recovery is the continuation of system operations by terminating 
the user whe experienced the error. System recovery can take place only 
if the user in question is not critical to continued system operation. 
A system routine containing an error that is considered to be critical 
to system operation precludes functional recovery and would require 
logout and a system dump followed by reloading the system. 
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Ql££3ior Initiated Restart 

When the errors may have caused a loss of supervisor or system 
integrity, the system is put into a disabled ¥ait state. The operator 
must then reload the system. 

System Repair 

If system recovery is not possible, the system may require the services 
of maintenance personnel to effect a system hardware repair. System 
repair by this method occurs when the error is so critical to system 
operations that the system cannot be used to record the error. 

Machine Check Handler—Summary 

The machine check handler (MCH) consists of entirely resident routines 
in the CP nucleus. 

Recovery from most machine malfunctions on System/370 is initially 
attempted by the instruction retry, and the error checking and 
correction (ECC) machine facilities. However, if the retry or storage 
correction is unsuccessful, if the interrupted instruction is 
non-retryable, or if the storage failure cannot be repaired, RMS will 
assess the damage and do the following: 

• If the fault is an SPF key failure, refresh the key if conditions 
warrant such action. 

• If the fault is related to main storage, either (1) refresh that page 
or (2) have CP flag that page as unusable and assign a new page; then 
refresh the data if valid to do so. 

• Terminate or reset the virtual machine if the malfunction cannot be 
repaired but is traceable to a particular virtual machine. 

• Terminate all SCP operations and post a wait state code if system 
integrity is lost and nonrecoverable. 

• In attached processor applications, if the malfunction is associated 
with the attached processor while running in problem program state 
and attached processor recovery is not possible, cease all operations 
on the attached processor and allow the system to continue in 
uniprocessor mode on the main processor. 

• If the error is a channel group inoperative on a 3031, 3032 or 3033 
processor, place the system in a disabled wait state. 

Any of the above conditions can produce one or more of the following 
results: 

— Wherever possible, a record of the error is produced in the 
system's error recording area. 

— Wherever possible, the primary system operator is informed of the 
error. 

Errors corrected by instruction retry and main storage errors 
corrected by ECC are not reflected to the system operator's console, and 
these errors may or may not be recorded. See "Recovery Modes" in this 
section for a discussion of this. 

The messages produced by the machine check handler on supported 
VM/370 systems are described in IHZ370 System Messag es . Wait state 
codes 001 and 013 produced by the machine check handler routines are 
also described in VM/370 System Messages. 
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The action that the machine check handler takes for a given situation 
is determined by the error itself, the operating environment of VH/370, 
and whether the system was performing a CF function, a virtual machine 
function, or no function at all (a loaded wait state condition when the 
error occurred) . Figure 25 clarifies the action the system takes for 
the given situations. 



r . . .. — ., 
| | vn/370 Processing (CF) {Virtual Machine Processing ! 


| Error Condition | Uniprocessor | Attached Processor j Uniprocessor! Attached Processor! 
| 1 Operation | Operation | Operation | Operation | 


I j j Hain | Attached! j Bain | attached j 


I Invalid machine! 1 | 1 | 1 | 1 j j 1 | 1 | 
(check interrupt | II! Ill 
I code j III ! I I 


•Invalid PSS I 1 |1|1| 1 |1|1| 
I data j III 111 


j Register, | 1 | 1 | 1 j 1 j 3 | 3 | 
j Program mask j III III 
I instruction I III II! 
(address invalid! Ill III 


| System damages | 1 I 1 I 1 I 1 j 3 j 3 | 


| TOD or CPU | 1 11| 1 1 1 |1|3,4| 
j Clock Errors | III III 


IBultibit | 1 | 1 | 1 | 3,2 | 3,2 | 3,2 J 
I (solid) Storage! Ill III 
I error | III III 


IBultibit | 1 | 1 | 1 | 3,2 | 3,2 | 3,2 | 
I (intermittent) | III I I I 
I storage error | III III 


| Storage Protect! 1 I 1 I 1 I 3 | 3 | 3 I 
j Key (solid) j III III 
| failure | | | | III 


| Storage Protectl 2 |2|2| 2 |2|2| 
I (intermittent) | I i I I I I 
I failure j j | j | I j 
i i ill ill 


i j i i i i i i 
IBalfunction | 5 I 1 | 1 | 5 ( 1 I 3,4 | 
I alert | III III 


I Channel group I 1 |1|1| 1 I 1 I 1 I 
| inoperative | III III 


I legend : j 
| 1 = load wait state PSH I 
I 2 = refresh for retry operation I 
| 3 = terminate the virtual machine I 
! 4 = automatic processor recovery I 
I 5 = Not applicable ! 



Figure 25- Condition/Action Table for Uncorrectable Errors 
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KJCUUWEKX HQDES 

The System/370 processors and main storage have error detection 
circuitry integrated into their logic. This error circuitry has 
additional hardware logic that allows the correction of soie generated 
error conditions. They are: 

• Certain processor error conditions 

• Main storage single-bit errors (within a doubleword) 

The detected processor errors cause the system to retry or circuiveDt 
the failing function, while main storage single-bit failures are 
corrected by error correction code (ECC) hardware logic. These errors 
(called soft errors) , when detected and corrected, impose no adverse 
conditions upon the operating system. These errors are also generally 
not apparent to the users of the system. 

Because soft errors are automatically rectified and are related to 
the fastest part of system hardware, they could, if no controls were 
imposed upon them, quickly fill the error recording area. To prevent 
this from happening, VM/370 maintains a program counter to record the 
number of soft errors that are recorded on the error recording area. 
This counter, initially reset on system initialization, can accumulate 
up to a count of 12. At the count of 12, control register (CR) 14 bit 4 
(also initiated to the OH condition upon system initialization) is 
turned off. With the turning off of this bit, soft errors are no longer 
recorded in the error recording area. The system operator receives a 
message informing him that soft errors are no longer being recorded. 

Not all of the various System/370-supported systems initiate soft 
error recording in the same way. All VM/370 supported processors, with 
the exception of the 155 II and 165 II, are disabled for ECC (error 
checking and correction) at system initialization. All processors, 
including the 4331, 4341, and the 3031 AP, are enabled at system 
initialization to record processor retry. 

After system initialization, in order to change the mode of soft 
error recording, the SET MODE command must be invoked. In attached 
processor applications, SET MODE values can be set for either the main 
or the attached processor or both processors if desired. The SET MODE 
command can only be used by privilege class F users. 

Note: The SET MODE MAIN command is treated as invalid od the 3031, 3032, 
or 3033 processors, and the 3031 AP. 

On all ether processors, SET MODE may be invoked in any of the 
following ways: 

SET MODE MAIN RECORD [cpuid] 

This instruction resets the error recording counter and turns CR14 bit 4 
on, so that VM/370 can record ECC-corrected errors. 

SET MODE RETRY RECORD [cpuid] 

This instruction resets the error recording counter and turns CR14 bit 4 
ON, so that VM/370 can record processor errors that were rectified by 
retry or circumvention techniques. 

SET MODE MAIN QUIET 

This instruction inhibits the recording of ECC-corrected storage errors 
only. 
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SET MODE RETRY QUIET 

This instruction turns CR14 bit 4 off, thus inhibiting the recording of 
all soft errors. 

By specifying the cpuid (valid for attached processor operations 
only), SET MODE values can be specified for a particular processor = By 
not specifying the cpuid, the SET MODE values are applicable to both 
processors. 

While in record mode, corrected soft errors are formatted and 
recorded in the VM/370 error recording area. The primary system 
operator is not informed of the occurrence of these recordings until the 
recording of such errors is stopped by a command or, automatically, by 
count control. 



Channel Check Handler 

There are four types of channel checks caused by hardware errors: 

• Channel data check - (Bit 44 set in the CSW) . 

• Channel control check - (Bit 45 set in the CSW) . 

• Interface control check - (Bit 46 set in the CSW) . 

• Interface inoperative - (Bit 46 is set in the CSW with bit 27 of the 
limited channel logout (LCL) set at the same time) . Interface 
inoperative is a rare but usually persistent hardware problem with 
one control unit that affects the entire channel. Hote: This 
condition is only recognized on the 3031,, 3032 and 3033 processors. 

The channel check handler receives control from the I/O supervisor 
when any of the channel checks listed above is detected. For these 
channel conditions, CCH does the following: 

• Records the results of CCH error analysis in the IOERBLOK (I/O error 
block). If the error is an interface control check or a channel 
control check, device-dependent error retry procedures (ERP) will use 
the data in the IOERBLOK for the subseguent retry operation. 

• Constructs a record describing the error environment. 

• Informs the proper module so the error record will te written in the 
error recording area. 

• Sends a message to the system operator regarding the error incident. 

• Sets logout areas and the ECSW to all ones. 

• Reflects the error to the virtual machine if it is the result of a 
SIO issued by a virtual machine. The manner cf reflection depends en 
the processor and channel models; in addition to the CSW, the limited 
channel logout (LCL) and extended channel logout are reflected as 
appropriate, depending upon the model. If the setting of the virtual 
machine's control register 14 masks out the extended channel logout, 
the extended channel logout data is not kept pending and is lost to 
the virtual machine, but still is recorded in the VM/370 error 
recording cylinders. Figures 26 and 27 show, in greater detail, 
under what circumstances the various channel checks are reflected to 
the virtual machine. 
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Figure 26. Handling of Channel Check, Channel Control Check, and 
Interface Control Check 
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Figure 27. Handling of Interface Inoperative 



CHANNEL CHECK HANDLER— INITIALIZATION 

To be effective, CCH must be tailored to the resident system operating 
environment. This is done during the CP initialization phase by the use 
of the Store Channel ID instruction (STIDC) and the Store Processor ID 
instruction (STIDP) . 

By using the STIDP instruction, it can be determined whether the 
processor is a 165 II, or 168 or some other VH/370-supported system. If 
it is a 165 II or 168, then a determination must be made to find out 
what type of standalone channels are attached to the system. This is 
done by using the STIDC instruction,. When the type of channels is 
determined, the related standalone channel program modules are loaded 
and locked into main storage. If the system is not a 165 II or 168, 
support for the integrated channels is provided. 

Besides determining the processor and channel types, CP 
initialization does the following: 

• Obtains storage for maximum I/O extended logout area for the 
VM/370-supForted system. 

• Initializes logout and ECSW to all ones. 

• Sets up the I/O extended logout pointer, if one exists for the 
supported system. 

It is only after this initialization that CCH can assist the system 
in its error recovery function. 
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CHANNEL CHECK HANDLER — SUMMARY 

CCH receives control from the I/O supervisor when a channel check 
occurs- CCH produces an I/O error block (ICERBLOK) for the error 
recovery procedure and a record to be written in the error recording 
area for the system operator or customer engineer- The VM/370 system's 
operator or customer engineer may obtain a copy of the record by using 
the CMS CPEREP command. A message about the channel error is issued to 
the system's operator each time a record is written in the error 
recording area. 

When the input/output supervisor program detects a channel error 
during routine status examination (following the issuance of an I/O 
instruction or following an I/O interruption) , it passes control to the 
channel check handler. If the error is a channel control check cr 
interface control check, CCH analyzes the channel logout information and 
constructs an IOERBLOK, and, if the error is not a channel data check, 
an ECSfl is constructed and placed in the IOERBLOK. The IOERBLCK 
provides information for the device-dependent error recovery procedures. 
CCH also constructs a record to be recorded in the error recording area. 
Normally, CCH returns control to the I/O supervisor after constructing 
an IOERBLOK and a record. However, if CCH determines that system 
integrity has been damaged (system reset or invalid unit address) , then 
system operation is terminated. For system termination, CCH issues a 
message directly to the system operator and places the processor in a 
disabled wait state with a recognizable wait code in the processor 
instruction counter. 

Normally, when CCH returns control to the I/O supervisor, the error 
recovery procedure is scheduled for the device that experienced the 
error. When the ERP receives control, it prepares to retry the 
operation if analysis of the IOERBLOK indicates that retry is possible. 
Depending on the device type and error condition, the ERP either 
recovers or marks the event fatal and returns control to the I/O 
supervisor. The I/O supervisor calls the recording routine to record the 
channel error. The primary system operator is notified of the failure, 
and the recording routine returns control to the system and normal 
processing continues. 

If the channel check is associated with an I/O event initiated by a 
SIO in a virtual machine, the logout is reflected to the virtual machine 
in one of two ways, depending on whether the channel check occurred at 
SIO time, or later in an interrupt. If it occurred at SIO time, the SIC 
routine calls CCH to reflect the logout. If it occurred in an I/O 
interrupt, the dispatcher notices the channel check as it is reflecting 
the I/O interrupt to the virtual machine, and at that time the 
dispatcher calls CCH to reflect the channel logout. 
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VM/370 Channel Check Handler action is summarized in Figure 28. 
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I ^Action Codes: 
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I 2 = Schedule system termination with prope 
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figure 28. Channel Check Action Table 



All messages that are the result of the channel check handler are 
prefixed by the designation DMKCCH and are described in the publication 
VM/37 Syst em Messages. Action by the channel check handler can also 
force the system into wait state 002. Operator action for the wait 
state condition is also described in VM/370 System Messages. 



Other E rror Messages and Wait State Codes 



There are three critical phases of VM/370 CP operations where continuous 
system operation is vulnerable and may degenerate to wait state codes as 
a result of machine check or fatal I/O error conditions. They are: 
during VM/370 CP initialization, during system checkpoint activity and 
during the occurrence of system dump operations. 

The resultant messages and wait state codes are produced by other 
system modules (other than DMKCCH and DMKMCH) . Consult VM/370 System 
Messages for a description of these messages and wait state codes. 



FIXED STORAGE ASSIGNMENT AND L0GO0T AREAS 



The storage areas that concern CCH and MCH for error analysis are 

• Permanent storage assignments 

• I/O communications areas 

• Fixed logout area 

• Extended logout area 
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figure 29 shows details of these areas. 



r ■ ■" •% 

I | logs out at I III 1 
i i „ , i i i i i 


i r 1 i i l i 
! ! i location I 1 1 1 1 
I | | pointed | length of | j LCL j unit i 
| | fixed | to by | logout in | CSW | (ECSfl) | address | 
I channel j location | location j bytes | at | at | at | 


| 2860 | 304 | | 24 | 64 | | | 


| 2870 | 304 | | 24 | 64 | | | 


I 2880 | | 172 | 112 | 64 | | | 


| 145/148 | | 172 | 96 | 64 | 176 | 186 | 
I 145-3 | | | maximum III I 


| 135/138 | 256 | | 24 | 64 | 176 | 186 | 
j 135—3 | | ! maximum III 1 


I 155/158 | 155 S 158 channels do not log out | 64 | 176 | 186 | 


I 4331 | No fixed or I/O extended logout | 64 | 176 | 186 | 
I 4341 | areas III I 


I 3031 | | | ill! 
I 3032 | | 172 | 640 | 64 | 176 | 186 | 
I 3033 | | | I I I I 


I NOTE: All numbers in this figure are decimal. 3031, 3032 and 3033 | 
I have integrated channels. The 2880, 2870 and 2860 channels | 
I cannot be attached to these processors. Their channels are j 
I similar to H145 channels in that both a LCL and an IOEL are | 
I produced. j 



Figure 29. VM/370 Fixed Storage and Logout Areas 
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Section 4. Additional CE Aids 



• CPEREP ana OS/VS EREP 

• SET RECORD and SET MODE Facility 

• TRACE Facility 

• 7HFDDMP 
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VM/370 CPEREP and OS/VS EREP 



CPEREP reads system error records from the VM/370 error recording area 
and produces printed reports. CPEREP can also be used to copy the error 
records to tape and to clear the VM/370 error recording area. 

The OS/VS Environmental Recording, Editing, and Printing Program 
(EREP) is executed when the CMS CPEREP command is invoked. CPEREP 
provides the virtual machine user with all the facilities of OS/VS EREE. 
The reports generated by CPEREP have the same format as those generated 
on an OS/VS system. The content of the reports depends upon the 
specified (or defaulted) CPEREP operands and upon the input system error 
records. The input system error records may be from the VM/370 error 
recording area or from a history tape. The history tape may have been 
produced earlier by CPEREP from VM/370 error recording area data or by 
an OS/VS system from SYS1.L0GREC data. Onlabelled tapes produced en 
OS/VS systems by OS/VS EREP and on VM/370 systems by CPEREP are 
compatible and can be transported between systems. Data from multiple 
systems can even be accumulated on the same tape . 

OS/VS EREP is documented in existing OS/VS publications, but the 
VM/370 CPEREP command is not described there. Therefore, the function 
of this chapter is to: 

• Describe briefly the capabilities of OS/VS EREP 

• Describe in detail how the CPEREP command is invoked 

• Describe the CPEREP interface to OS/VS EREP 

• Refer to the OS/VS publications for details on operands and the 
reports OS/VS EREP produces. 

Publications 

Because OS/VS EREP is not a program exclusively used with VM/370 and 
because it is not part of the VM/370 system reference library, the user 
must use the latest OS/VS1 or OS/VS2 publication that describes EREP. 
Changes and enhancements to EREP documented in the OS/VS Publications, 
because of the level of the detailed information and the fact that 
OS/VS1, OS/VS2 and VM/370 do not adhere to the same publication print 
cycle, may not be documented in the VM/370 publications. 

The VM/370 user requires the following publications: 

VM/370 OLTSEP and Error Recording Guide, Order Ho. GC20-18Q9 

OS/VS. DOS/VSE, VM/370 Environmental Recording Editing and Printing 
(EREP) Program, Order No. GC28-0772 

The above publications give details on operands used by CPEREP 
and describes the outputs. 

11/370 S£stem Messages, Order No. GC20-1808 

The user should be aware that error messages may originate 
from the CPEREP program with a DMS prefix or they can 
originate from OS/VS EREP with an IPC prefix. In addition to 
its DMS section for CMS, VM/370 System Messages contains an 
IFC message section devoted to EREP. This section does net 
describe all possible EREP messages, but it does describe all 
EREP messages that are likely to be issued in the VM/370 
environment. 
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The VM/370 user, in rare instances, nay require the following 
publication which describes the full set of possible EREP messages: 

OS/VS, PjQS/VSE, VM/370 EREP Messages, Order No. GC38^1045 

Logic information pertaining to CPEREP and OS/VS EREP is contained in 
the following publications: 

IM/370 Service Routines Program Logic, Order No. SY20-0882 

This describes the CPEREP modules, DMSIFC and DMSREA. 

OS/VS, DOS/VSE. VM/370 Environmental Recording Editing and Printing 
(EREP) Program Logic, Order No. SY28-0773 

If error records from a 3850 Mass Storage System (MSS) are to be 
processed, then one or both of the publications listed below are 
required. These publications describe the use cf the VS1/VS2 Subsystem 
Data Analyzer (SDA) program (ISDASDAO) . This program runs under VS1 or 
VS2 operating systems and is used with SYS1-LOGREC data set information 
for the generation of analysis and performance reports for MSS hardware. 

OS/VS1 SYSJLLOGREC Error Recording, Order No. GC28-0668 

OS/VS2 System Programming Library: SYS1.LOGREC Error Recording, 
Order No. GC28-0677 



CPEREP and OS/VS EREP - An Overview 

In the VM/370 system, the CMS CPEREP command provides access to the 
OS/VS EREP program. Operands are supplied to CEEREP via a control file 
and/or prompted console input. The CMS module DMSIFC called by the 
CPEREP command provides an initial screening and edit of the operands 
that are passed to IFCEREP1 (a module of OS/VS EREP) for the edit and 
printing phase of EREP. IFCEREP1 does the final screening of the 
supplied operands and initiates error record retrieval activity and the 
requested edit and print function. Because the format of the VM/370 
error recording area differs from the format of a SYS1.L0GREC data set, 
the method of error record retrieval and erasure from DASD differs. To 
circumvent format incompatibilies, DMSIFC causes EREP's I/O operations 
to the OS/VS SYS1.LOGREC data set to be trapped and simulated. DMSIFC 
performs the simulation and in the process it calls on DMSREA to read 
records from the VM/370 error recording area. For other files required 
by EREP, DMSIFC does not perform the I/O simulation; it merely issues 
FILEDEFs for them. For these files the standard simulation of OS files 
provided by CMS is adequate. 

The formats of the individual records in the OS/VS SYS1.L0GREC data 
set and the VM/370 error recording area are identical; however, VM/370, 
through the medium of SVC 76, does not record on its error recording 
area all error record types. On the VM/370 system, errors passed to 
VM/370 for error recording {via SVC 76) that do not adhere to VM/370 
standards are reflected to the virtual machine to record the error on 
its own error recording data set. 

The error record types recorded by VM/370 as opposed to the record 
types recorded by OS/VS1 and 0S/VS2 operating systems are shown in 
Figure 30. Although the process of recording errors has been summarized 
here, it should be noted that CPEREP and OS/VS EREP are only involved in 
reading the error records for reporting purposes and are not involved in 
writing the error records at the time of their occurrence to the 
recording medium be it SYS1.LOGREC data set or VM/370*s error recordiDg 
area. 
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OS/VS Recorded Errors 


VM/370 Recorded Errors 


1X Machine Check (MCH record) 1 
10 MCH. 
13 MCH in multiple storage environment. 


1X 


Machine Check (MCH record) 
10 MCH. 


2X Channel Check (CCH record) 1 ■ 3 

20 CCH. 

21 CCH in multiple storage environment. 


2X 


Channel Check (CCH record) 
20 CCH. 


3X Unit Check (OBR record) 
30 OBR (unit check). 
34 TCAMOBR. 
36 VTAMOBR. 


3X 


Unit Check (OBR record) 
30 OBR (unit check). 2 


4X Software Error (software record) 

40 Software detected software error. 
42 Hardware detected software error. 
44 Operator detected error. 
48 Hardware detected hardware error. 
4F Lost record summary. 


4X 


Software Error (software record) 

40 Software detected software error. 

42 Hardware detected software error. 

44 Operator detected error. 

48 Hardware detected hardware error. 

4F Lost record summary. 


5X System Initialization (IPL record) 1 
50 IPL. 






6X Reconfiguration (DDR record) 
60 DDR. 


6X 


Reconfiguration (DDR record) 
60 DDR. 


7X Missing interruption (MiH record) 
70 Missing interruption handler. 


7X 


Missing Interruption (MIH record) 
70 Missing interruption handlsr. 


8X System Termination (EOD record) ' 
80 EOD. 






9X Non-Standard (MDR record) 

90 SVC 91. 

91 MDR. 


9X 


Non-Standard (MDR record) 
91 MDR. 


1 When OS/VS uses SVC 76 to try to record this record type VM/370 ignores the record; that is, it does 
not record it. Instead, VM/370 reflects the SVC 76 interruption back to the virtual machine. OS/VS will 
then record the record in its own error recording dataset. 


2 Of several record types DOS or DOS/VS passes to 
OBR (unit check), is accepted and recorded. AM c 


VM/370 by 

thor h/noc a 


means of an SVC 76, only one type, 30 
r e reflected back to the virtual machine. 


3 Record type 2X (channel check) is ignored and reflected back to the virtual machine that issued the 
SVC 76. This is because VM/370 already recorded the error before the virtual machine detected the 
channel check condition. 



Figure 30. VM/370 vs OS/VS1 and OS/VS2 Error Record Types Recorded 



Figure 30. VM/370 vs 0S/VS1 and 0S/VS2 Error Record Types Recorded 
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EIFFERENCES/EXCEPTIONS IN VM/370 SUPPORT OF OS/VS EREP 

The OS/VS emergency offload program (IFCOFFLD) of EREP nodules is net 
supported by VM/370. Function performed by IFCOFFLI (that is # the 
program that is used to quickly dump a SYS1.L0GREC error recording data 
set to a history tape during an emergency when time and circumstance do 
not permit an EREP to printer run) can be performed by CPEREP in 
conjunction with a user created control file (details on how this is 
done are described further on in the text) . 



Using CPEREP and the Facilities of OS/VS EREP 

To use the CPEREP command, the user must invoke the command from the CHS 
environment; the user must have privilege class C, E, or F to access 
records in the VM/370 error recording area. To erase the VM/370 error 
recording area, the user must have privilege class F. 

CPEREP as depicted in this text is consistent with the same 
notational conventions as used in the VM/370 publications to describe 
other commands. Briefly, operands in brackets ([ ]) indicate one operand 
may be selected; for operands nested in braces ({ }) one operand must be 
selected. Operands that are underscored (_) are default values. 
Parentheses, commas, periods, and egual signs must be entered as shown. 
All lowercase operands indicate variable values that are to be entered. 
Uppercase values indicate the keywords that must be entered for the 
functions that are to be performed. 

For a full description of VM/370 notational conventions, refer to the 
VM/370 CP Command Reference for General Users. 

The format of the CPEREP command with available operands is shown in 
Figure 31. "CPEREP Command Format". Syntactical rules for specifying 
operands are given under the following topic: "Entering CPEREP and EREP 
Operands". A brief description of the keywords used with CPEREP is 
contained in Figure 32. No attempt is made in this publication to 
describe the precise meaning and use of operand values that are required 
with the user supplied keywords. Also (except for Figure 33, which 
shows the reports that can be generated and the operands allowed with 
each report) , no attempt is made to explain the relationship of keywords 
to one another,. Some keywords are used with each other and at the same 
time disallow the use of other keywords. For details on OS/VS operands 
and the unigue operand to operand relationships, refer to the OS/VS EREP 
publication. Details on the operands (CLEAR, CLEARF, and TERMINAL) that 
are unique to VM/370 are covered only in the present publication, not in 
the OS/VS publication. 
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CPEREP | [filename filetype [filemode]] 



The operands that follow cannot be entered on the command line. 
Enter operands via prompting technique or from file specified as 






r r n 

iAcci=mn 

I i (Njii 

L L JJ 

r i 1 

I CLEAR | 
ICLEARF | 

L J 

[CPD=serialno.modelno[ ,serialno.modelnc, 
[ CPUCUA= (serial. addr, serial. addr[ , serial 

r 

I CTLCRD ( date1[ date2[ interval[ title ...]]] 

I \ datel ,[ date2 ], [ interval ]„[ title 

L 

[CUA=(addr[ ,addr,.,. . ]) ] 

[DATE=(yrday[ f yrday]) ] 

[BEV= (devtype[ .devtype,... ]) ] 

[ DE¥SER= (seriai[ , serial, . . . ]) ] 

[ ERRORID= (seqno[ ,cpuid,asid,hh,mm„ss,t ]) 

r r 

|EVENT|= 

I I 



.addr, 

, 2 



• 3)3 



{Hi 



r r n 

lHisTi=jN)i i 
I I iy/ii 

L L J J 

[LIBADR=addr] 
[LINECT=nnn]" 

r r ii 

|MERGE|=(Yl| | 



'«}! 



jj 



1 Operand exclusive to VM/370. 

2 After entering the CTLCRD operand and associated data, no further 

operand can be entered on the same command line; the next operand 

must begin on a nev line. 



Figure 31. CPEREP Command Format (Part 1 of 2) 
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CPEREP 
(cont.) 



r r n 

|MES|= 

I I 

L L J J 

[MOD= (iodelno[ ,iodelnc. . . ]) ] 



n 




r r 

|RDESUM|= 



m 



ii 



|SHARE= 



(cua) /cua) j 
(serial.\cuX j, serial- \euX/ # . . .) I 



r r 

| SHORT |= 



\l) 



n 

II 

I I 
j j 



r t 

|SYHCDE=/nnnn\| 
I )nnnx(| 

I \nnXX?| 

I (nXXx)| 

L J 

fsYS0M| = m|| 
I I INJII 

L L JJ 

[TABSIZE=sizeK] 

r r n 

I TERMINAL | = /Y\ | | 



V«}\ 



L L J J 

[ TERMN=terinaie ] 

[THRESHOLD= (teipread, tenpwrite) ] 

[TIME=(hhii,hhn) ] 

r r -n 

|TRENDS|=/Y)| | 

I I UJII 

I L JJ 

[TYPE=[C][D][E][H][I][M][0][S][T]] 
[V0LID=(volid1[ ,volid2[ ,volid3[ ,volid4]]]) ] 

r r n 

|ZERO|=/Y\|| 

I I Wll 



|*Operand exclusive to VM/370 

i. 



Figure 31. CPEREP Coimand Format (Part 2 of 2) 
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| Operand 
I 



ACC= 



Description 

Indicates that selected error records are to be accumulated 
in an output data set. The particular error records 
selected and the source of these records 'either the VM^370 
error recording cylinders, or a history file, or both) 
depends on ifhat other operands are eeded> The output 
accumulation data set is normally a tape mounted on tape 
drive 181, but this can be changed (see the section "CPEREP 
FILEDEFS") . When output is accumulated on tape 181, the 
output is added as an extension of the existing file: the 
tape is rewound and then spaced out to the end of the first 
file prior to writing- Therefore, if a tape is to be used 
for the first time, the user should write a tape mark at 
the beginning of the tape before invoking CPEBEP (the CHS 
TAPE command can do this) . When output is accumulated on a 
tape, the tape should be mounted, readied, and attached to 
the user's virtual machine as tape 181 prior to invoking 
CPEREP. Hote that for most types cf reports, ACC=Y is the 
default. 



CLEAR 
CLEARF 



CLEAR clears all error records from the error recording 
area, but does not clear the SRF frame records. CLEARF 
clears the SRF frame records from the error recording area, 
as well as error records subseguent to re-reading the SBF 
frames, and writing the frame records at the beginning cf 
the error recording area. A CLEAR or CLEARF operand cannct 
be invoked with other operands. It must be invoked in a 
standalone manner. Therefore, the user should capture 
pertinent error area information before invoking one of 
these operands. It is recommended that the user acguaint 
himself with the ZERO operand for erasing the VM/370 error 
recording area. The ZERO operand is used in conjunction 
with report generation operands and does not execute the 
erase process until the report generation process is 
complete. The service support console must be in SRF mode. 

Note; The CLEARF operand is designed for the 3031, 3032, 
and 3033 processors. CPEREP should be invoked with CLEARF 
specified after the installation of engineering changes to 
the processor and channels. To access the SRF (1) enable 
the I/O interface for the service support console, (2) 
activate the C1 frame, (3) select SRF mode (A2) for 3031 
and 3033 processors (SRF appears disabled until accessed en 
the 3032) , (4) vary on SRF, and (5) attach the SRF to the 
console of the class F user running CPEREP. CLEARF clears 
error records on a 158 or 168 processor. 



CPU 



An error record selection operand. — It allows the selection 
of error records by the central processor unit's serial and 
model number. Multiple processor values may be specified 
as multiple sub-operands of CP0. 



CPOCDA I An error record selection operand. — It allows the selection 
cf error records that relate to a specific processor 
(serial address) and an attached device (cuu) address. 
Multiple processor and devices can te specified as multiple 

sub-operands of CPOCDA. i 

,. — i 



Figure 32. Operands Used with CPEREP (Part 1 of 5) 
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I Operand 

I 

CTLCRD 



I Description 

H 

An error record selection operand. — Uhen the RDESOH operand 
requests an IPL report, CTLCRD controls the selection of 
error records via its span of dates and IPL clustering 
interval. 

Mote; This operand and the datel, date2, interval, and 
title operands associated with it must be completed on one 
line of input and must not be followed by any other 
operands on this one line of input. 



CDA= 



An error record selection operand. — It allows the selection 
cf error records by specific device address a range cf 
device addresses, all the devices on a particular control 
unit, and all the devices on a particular channel. 
Multiple address values or ranges of values can be 
specified as multiple sub-operands of CDA. 



DATE= 



An error record selection operand. — It allows the selection 
of error records by the date or span of dates (Julian day 
values) specified. 



EEV= 



An error record selection operand. — It allows the selection 
cf error records by device type (for example, 2314, 3330). 
Multiple device types can be specified as multiple 
suboperands of DEV. 



EEYSER= 



An error record selection operand. — It allows the selection 
cf error records by the specific device serial number in 
the service data field in the error record. This operand 
is valid for only 3410/3120 devices. Multiple device 
serial numbers can be specified as multiple suboperands cf 
DEVSER. 



ERRORID= 



An error record selection operand. — It applies only to MCH 
and software records generated by OS/VS2 MVS. It allows 
selection by the five digit error identifier alone or by 
the five digit error identifier, processor identifier, 
address space identifier, and date/time values. 



EVENT= 



A report generation operand. — Th 
line abstracts of all or sele 
chronological order. 



is operand generates one 
cted error records in 



H 



BIST= 



Indicates that the source of the er 
is to be a history data set rathe 
recording cylinders. A history dat 
was created as an accumulation (A 
earlier session. Usually, the his 
mounted on tape drive 182, but this 
section "CPEREP FILEDEFs") . When 
tape, the tape should be mounted, 
the user»s virtual machine as tap 
CPEREP. 



ror records for this run 
r than the VH/370 error 
a set is a data set that 
CC) data set during an 
tory data set is a tape 

can be changed (see the 
input is from a history 

ready, and attached to 
e 182 prior to invoking 



Figure 32. Operands Used with CPEREP (Part 2 of 5) 
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i Operand 

I 

LIBADR= 



i Description 



An error record selection operand. — It allows the selection 
of error records by the four-digit hexadecimal line 
interface base address. 



J-USBCI^. 



4..-A4i-jaaii^uii^re|ior.t..i.Qrjiatt.ijig. op_er and, —This operand defines 
the number of lines of error data that are to be printed en 



MERGE= 



Indicates that the source of the error records 
is to be both a history data set and the 
recording cylinders. The history data set is 
earlier for the HIST operand. 



for this run 

VH/370 error 

as described 



MES= 



MOD= 



A report generation operand. — This operand 
generation of a Media Error Statistics R 
operand is valid for processing 341C and 3420 
subsystem records. 



allows the 
eport. This 
magnetic tape 



An error record selection operand. — It allows 
of error records by specified processor model 
for example, 158 or 3062. Multiple processor 
■ay be specified as suboperands of HOD. 



the selection 

designation; 

model numbers 



PRINT= 



A report formatting operand. — Values supplied with this 
operand in conjunction with other operands produce: 

SD - A printed summarization of all selected error records. 

PS - A printed summarization as well as the full printout 
of all selected errors. 



PT 



Full printing of all selected error records only. 



NO - No printed output. 



~l 



RDES0M= 



A report generation operand — This operand allows the 
generation of the IPL Report produced by the RDE Summary. 
The IPL report contains each IPL in the sequence of 
occurrence with the date, time, and reason for the IPL and 
the subsystem, if any, that was responsible for the IPL 
action. 

Note: With VM/370 error recording area data there will be 
nothing to report as VM/370 does not record IPL records to 
its error areas. However, RDESOH may te invoked when 
processing history tapes generated by another operating 
system which include the RDE option. 



Figure 32. Operands Used with CPEREP (Part 3 of 5) 
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j Operand | Description 

I 1 

SHARE= I In an installation where several processors share a device 
or where channel switches (or similar features) provide 
■ultiple paths to a device, this operand identifies all cf 
the equivalent addresses of a particular device or control 
unit. From 2 to 6 equivalent addresses may be specified as 
multiple sub-operands of SHARE. The SHARE operand may be 
specified more than once and is generally used once for 
each shared device or control unit. 

■hen a device is shared by more than one processor, I/O 
errors are recorded in the error log of the processor in 
control at the time of the error. If the error logs cf 
several processors are accumulated on a single tape, a 
SHARE operand for the shared device allows EREP to bring 
together and report all of the errors for the device 
regardless of where they were recorded,. 



SHORT= 



An error record selection operand. — When specified in 
conjunction with the PRINT operand, this operand suppresses 
the printing of short OBR (outboard recordings) records. 



SYMCDE= 



An error record selection operand that a 
of recorded error records whose sens 
supplied values. This operand is va 
devices. 



Hows the selection 
e tyte bits match 
lid for DASD 33xx 



SYSUM= 



A report generation operand. — Selectio 
produces a System Summary Report, 
comprehensive condensed report on the pr 
a system, that is, the processor, chann 
and the system control program. 



n of this operand 
This report is a 
incipal elements cf 
els, storage, I/C, 



TABSIZE= 



An EREP processing operand. The value 
operand defines the size of the sort t 
processing error records. 



supplied with this 
able to be used in 



Bote: If a value substantially greater than 21K is 
specified, it may be necessary to increase the storage size 
of the virtual machine in order to execute EREP programs. 



TERMINAL= 



A CPEREP operand that is not passed 
CPEREP encounters this operand while re 
a file of operands, it causes CPEREP to 
records from the file and to begin pro 
at the terminal instead. All operan 
record are processed before going to 
subsequent records in the file, if any 
CPEREP encounters this operand while 
terminal, it is ignored; control cannot 
the disk file,. 



on to EREP. — When 
ading operands from 
discontinue reading 
mpting for operands 
ds on the current 

the terminal, but 
, are ignored. If 

reading from the 
be switched back to 



TERBN= I An error record selection operand. — Values supplied with 
this operand are the 1 to 8-character alphameric names 
applied to terminals as used via VTiM and TCAM operations. 



Figure 32. Operands Used with CPEREP (Part 4 of 5) 
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joperand | Description 
I h 



THRESHOLD= 



TIME= 



A report generation operand — This 
and 3420 series tape systems, a 
THRESHOLD values for the number 
temporary write errors that occu 
established, only those devices th 
values are printed. 



operand, used with 3410 
Hows the user to set 

of temporary read and 
r. flith these values 
at exceed the THRESHOLD 



An error record selection operand, 
the user to select a time span for 
records that occurred within that t 



— Supplied values allow 
the processing of error 
ime span. 



TRENDS= 



A report generation operand. — The 
summarization of error counts per 
groups that comprise the system ins 



TREND Report provides a 
day on the component 
tallation. 



TYPE= 



An error record selection operand 
this operand allow the user to sel 
be processed. Valid record type 
records (code C) , dynamic device 
(code D) , end-of-day records (cod 
handler records (code H) , initia 
(code I) , machine check records ( 
records (code 0) , program error 
miscellaneous data records (code T) 
specified, all record types are pro 



. — Values supplied with 
ect the record types to 
s are: channel check 
reconfiguration records 
e E) , missing interrupt 
1 program load records 
code H) , outboard (I/C) 
records (code S) , and 
If no record type is 
cessed. 



VOLID= 



An error record selection operand. — Allows error record 
selection by defined volume serial number values. This 
operand is valid for 34xx and 33xx subsystems. 



ZER0= I This operand is invoked to erase the error records from the 
VM/370 error recording area. The error area is erased 
after all other functions/operations of EREP have been 
successfully written out to the printer or to an 
accumulation tape. 



Figure 32. Operands Used with CPEREP (Part 5 of 5) 
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Event | 


1 
MES| 




Print 
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1 


I Keyword | 


= PS 


=PT 


=SD| 


=NO| 


eshold | 
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X 


1 




■ 
X 


X 


■i 

x I 


X I 


X| X| 






| CLEAR | 
1 1 






i 








I CLEARF | | | 






I CPU | 

i i, 






X 1 
1 


X 


X 


X 1 


X I 






x I 


I CPDCDA | 
l .... ,j._ 








X 


X 


x I 


X I 








1 T 

I CTLCRD | 












1 1 X | | | | 


I CDA | 


X 




x I 


X 


X 


X 1 


X I 


i i 


x I 

1 


X 1 


1 "T" 

I DATE | 


X 




X 1 


X 


X 


X 1 


X I 


1 X | 
1 1 


X 1 
1 


X 1 


I DEV | 


X 




x 1 1 


X 


X 


X 1 


X I 


1 X | 


XI | 




| DEVSER | 






X 1 
1 










1 1 


1 


X 1 


i " " "T~ 

| ERRORID | 
l I. 






1 


X 


X 


X 1 


X I 








1 1 

I HIST | 
l _j.. 


X 




x I 


X 


X 


X 1 


X I 


1 x | 


X 1 


X 1 


r t 

I LIEADR | 
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Figure 33. Types of Reports, Showing Operands allowed with Each 
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Entering CPEREP and EREP Operands 

As mentioned previously, the class C, E, or F user must be in the CHS 
environment to invoke CPEREP. EREP operands can be supplied to CPEREP 
(DMSIFC) by means of a console prompting technique or fro* a previously 
generated file that contains the operands required for the desired EREP 
record output. 

The sequence for invoking CPEREP is as follows: 

1. Log on the CE's virtual machine. 

2. IPL CMS. 

3. Have the system operator attach any required tape devices to the 
virtual machine to serve for input and/or output data set use. 

(See description of the HIST and ACC operands) . 

tt« Enter CPEREP and EREP operands via the file entry method or by the 
prompting method. 

Note: The typical method of entering commands and operands on the 
same input line, as is done by other CP and CHS commands, is not 
valid. The reason that such action is disallowed is that many 
functions of EREP can exceed the maximum input line length allowed 
by VM/370. 



PROMPTING METHOD 

The CPEREP command is typed on the terminal followed by pressing the 
ENTER key. After a short pause, the system prompts the user with: 

ENTER: 

The user then enters CPEREP operands. If the user's needs exceed one 
line of input (limited by terminal line length) , the user types a few 
operands and then presses "the ENTER key again. The system then responds 
with the ENTER: prompt message again. The user may then enter more 
operands. The process is repeated until no more operands are required. 
When this occurs, the user presses the ENTER key to signal with a null 
line the end of the current string of operands. 

In entering operands, the following rules must be observed: 

• Keywords and their associated values must be separated from a 
following keyword operand by a blank (space) , or multiple blanks, cr 
by a comma. 

• Embedded commas, periods, and parentheses that define the extent of 
variable operands must be entered as indicated in the CPEREP command 
format structure previously described. 

• Keywords and keywords with their related variable operand (s) may be 
entered on the command input lines in any order. 

» When specifying a keyword where the allowed values are Y and N # the 
=Y may optionally be omitted, with the keyword alone being specified. 
This form of the operand will always be interpreted as a I 
specification regardless of the normal default value. 

• To initiate CPEREP with system default values, respond to the first 
ENTER: prompt message by pressing the ENTER key (enter a null line) . 

A sample illustrating the previous points is described later in the 
text. 
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PILE ENTRY METHOD 



The CPEREP command is entered followed by the filename, filetype, and 
filemode identity of a file that contains a "package" of CPEREP operands 
arranged in the format as described in the prompt method. The same 
rules regarding blanks, commas, and parentheses still apply. In 
addition, card images are truncated at column 71. 

In practice, a VH/370 installation would probably have multiple files 
containing various operand "mixes" to satisfy the installation CPEREP 
report needs. To create and generate the necessary CPEREP files for 
this method of entry, use the CHS EDIT command. File generation using 
the CHS EDIT command is described in the VH/370 CHS User's Guide. 



HIXED HETHOD 



The CPEREP command is entered followed by the filename, filetype, and 
filemode identity of a file of CPEREP operands, one of which is the 
TERMINAL operand. The operands are read from this file until the 
TERHINAL operand is encountered. At this point no further input is read 
from the file. Prompting begins at the terminal where additional 
operands may be entered. 



LOGON TO CPEREP EXECUTION — AN EXAMPLE 



The following example shows a complete CPEREP operation as initiated 
from the virtual machine console from the logon step to CPEREP 
completion. Lowercase letters indicate user entries, uppercase letters 
indicate VM/370 system response. The lozenge indicates an ENTER key 
action. 



Console Listing 
logon ce a 
ENTER PASSWORD: 



Comments 

Logon initiated 



Logon process completed 



LOGHSG-10:14:15 0*1/13/76 
♦RUNNING IPL5 
LOGON AT 10:54:13 
THURSDAY 04/13/76 

msg operator attach tape as 181 n User reguesting tape for CPEREP use. 

TAPE 181 ATTACHED 

Note that if HIST and ACC functions 
are to be invoked, two tape drives 
must be attached before invoking 
CPEREP. 



ipl cms a 

CMS VERSION 4.1-04/30/76 



Loads CHS. CPEREP can only be 
invoked after the CHS environment is 
entered. 
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cperep n 



GLOBAL TXTLIB ERPTFLIB EREPLIB 



CPEREP 



ESTER: 



print=ps dev= (3340) n 



ENTER; 



DATE - 116 77 

INPUT PARAMETER STRING 



CPEREP is invoked. 

No te ; CPEREP was invoked with no 

control file operand; therefore, the 

operation defaults to the prompting 

technique. 

The system response indicates that an 
EXEC has been executed and now EREP 
library members are available to 
process CPEREP requests. 

This system response indicates that 
CPEREP initialization is in progress. 

Message from CPEREP prompting f cr 
operand input. 

First line of CPEREP operand entry 
followed by pressing the ENTER key. 



CPEREP prompts 
input. 



•P*"k1- BAT^i 



operand 



Operand entry has been completed so 
the ENTER key is pressed again. This 
creates a null line. The null line 
indicates to the system that the EREP 
execution phase is to begin. 

EREP INFORMATIONAL MESSAGES 

PRINT = PS, BEV=(3340) 



PARAMETER OPTIONS VALID FOR THIS EXECUTION 

RECORD TYPES (MCH, CCH,ORD, SOFT, IPL, DDR, MIH, EOD, HER) ,PRINT (EDIT, SUMMARY, 

ACCUMULATE, LOGREC INPUT r DUMP SDR COUNTERS 

DATE/TIME RANGE - ALL 

TABLE SIZE - 024K,LINE COUNT - 050 
DEVICE ENTRIES 

DEVICE TYPES (OBR, MIH, DDR) -3340 (200A) 

DEVICE TYPES (MDR)-3340 (09) 
IFC120I 6 RECORDS THAT PASSED FILTERING 



OBR RECORDS 
SET RECORDS 
IPL RECORDS 
DDR RECORDS 
MIH RECORDS 
EOD RECORDS 



REQUESTED BUT 
REQUESTED BUT 
REQUESTED BUT 
REQUESTED BUT 
REQUESTED BUT 
REQUESTED BUT 



NOT FOUND 
NOT FOUND 
NOT FOUND 
NOT FOUND 
NOT FOUND 
NOT FOUND 



NUMBER OF MCH TYPE OF RECORDS READ WAS 1 
NUMBER OF CCH TYPE OF RECORDS READ WAS 1 
NUMBER OF MDR TYPE OF RECORDS READ WAS 4 



The above represents information frcm 
OS/VS EREP to the user indicating 
operand selection and OS/VS default 
values.. Also indicated is a synopsis 
of the EREP exercise. 



Though the previous example does not show a complex string of OS/VS EREP 
and CPEREP operands being used, it does show that the procedure itself 
is not difficult to use. Indicated in the example are information 
messages issued by the OS/VS EREP. CMS messages as well as other OS/VS 
EREP messages may also appear in the course of EREP execution. Consult 
the VM/370 System M essages for the meaning of messages prefixed by 
DMSIFCT DMSREA, and IFCxxxx. 
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Further insight into the functions performed by DMSIFC is reali2ed when 
you examine a typical example of an OS/VS EREP entry from a standalone 
0S/VS1 system as shown below. 



//EVENT 


JOB 


//STEP1 


EXEC 


// , ACC=N I 


) 


//ACCIN 


DD 


//DIRECTWK 


DD 


//TOURIST 


DD 


//EREPPT 


DD 


//SYSIN 


DD 


// 





PGM=IFCEREPl,PARM=('EVENT,EflTE=(76130, 76150) ,HIST» , 

DSN=EREP.HIST,DISP=OLD 
UNIT=SYSDA,SPACE=(CYL, (5)) 
SYSOUT=A,DCB=BLKSIZE=133 
SYSOUT=A,DCB=BLKSIZE=133 
DUMMY 



The EXEC job control statement, indicated by the arrow, shows a 
selection of OS/VS operands; it also shows the comma that is used as an 
operand separator. Job control statements are needed to define those 
data sets that are required for the OS/VS EREP execution process. In 
VM/370, CPEREP provides the data set requirements automatically. Fcr 
the VM/370 CPEREP process, operand separators are still required and 
VM/370 traditionally uses blanks. However, because much of the 
documentation and examples used are in OS/VS1 or OS/VS2 publications 
that indicate the comma separator, CPEREP uses either the comma cr 
blank. 



CPEREP FILEDEFs 



CPEREP issues the FILEDEFs listed below prior to invoking OS/VS EREP. 
These allow the corresponding EREP files to be simulated by CMS. 

FILEDEF EREPPT PRINTER ( NOCHANGE BLKSIZE 133 

FILEDEF SYSIN DISK SYSIN EREPWORK X3 

FILEDEF SERLOG DISK SERLOG EREPWORK ( BLOCK 4C96 

FILEDEF TODRIST TERMINAL ( BLKSIZE 133 

FILEDEF DIRECTWK DISK DIRECTWK EREPWORK X4 

FILEDEF ACCDEV TAP1 ( NOCHANGE RECFM VB BLKSIZE 1200C 

FILEDEF ACCIN TAP2 ( NOCHANGE RECFM VE BLKSIZE 1200C 

When a mode letter of X is shown, X represents the read/write disk 
that has the most free space when CPEREP is invoked. At the end of the 
run, the FILEDEFs listed above are cleared with the exception of the 
EREPPT, ACCIN, and ACCDEV FILEDEFs. For these, it is expected that the 
user may sometimes be supplying them and so they are left intact. 

For those FILEDEFs listed above where NOCHANGE is an option, the user 

can supply an overriding FILEDEF of his own prior to invoking CPEREP 

(but see explanations below) . The NOCHANGE option in CPEREP's FILEDEF 
means that it cannot change the user's prior FILIDEF. 

EREPPT This is EREP*s printer file to which the report output is 
sent. The user can override this FILEDEF with a FILEDEF cf 
his own which he can issue prior to invoking CPEREP. 

SYSIN This is a workfile, built by CPEREP, and read by OS/VS EREE. 
The user is not concerned with it. It generally is a file 
containing only a few records. It is placed on the 
read/write disk having the most available space, and it is 
erased automatically at the end of the run because its 
filemode number is 3. In those runs where there is no data 
tc go into SYSIN, CPEREP issues FILIEEF SYSIN DUBHY for it 
rather than the FILEDEF shown above. 
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SERLOG This represents the SIS1-LOGHEC data set of OS/VS. Since 
EREP's I/O to SYS1.L0GREC is trapped by D8SIFC, no I/O is 
ever performed with this FILEDEF. Nevertheless, the FILEDEF 
is required to satisfy the requirements of the OPEN and 
CLOSE issued by EREP since these are not trapped. Although 
a FILEDEF is defined, no corresponding file ever exists en 
any disk. 

TOURIST This is the message data set, directed to the user's 
terminal. EREP writes messages and diaanostics to this 
file. 

DIRECTWK This is a workfile, built and read by OS/VS EREP. It is net 
always created; whether it is created or not depends upon 
the particular report and whether or not the input comes 
from a history tape. This file may be quite large since it 
contains all input error records. The file is placed on the 
read/write disk having the most available space and is 
erased at the end of the run. 

ACCDE7 This is the accumulation file; normally - it is a tape en 
tape drive 181. This file is used if ACC=Y is specified 
either explicitly or implicitly. If ACC=Y is specified, 
tape 181 is rewound and spaced forward over the existing 
file and then backspaced over the tape mark before any 
writing is done. In this way, the tape is positioned to 
write new records at the end of the accumulation file. 



By issuing his own FILEDEF for JCCDEV before invoking 
CPEREP, the user can override CPEREP's FILEIEF; thus, he can 
accumulate to another tape drive or to a disk file. 
However, the positioning of tape 181 is independent of the 
user's FILEDEF and this causes two problems: (1) Regardless 
of the user's FILEDEF, CPEREP attempts to position tape 181 
as long as there is a tape 181 attached to the virtual 
machine (and provided that ACC-Y) . If 181 
ready, it is positioned; if attached but 
operator is notified and CPEREP waits for 
ready. The solution to this problem is to 
before running CPEREP. (2) The second problem is that 
CPEREP does not automatically position the user defined file 
before writing into it as it does when the file is tape 181. 
If the user defines the file to another tape drive, the 
solution to the problem is to issue appropriate CHS TAEE 
commands to position the tape before invoking CPEREP* If 
the user defines the file to a disk, the solution to the 
problem is for him to specify the DISP MOD option in his 
FILEDEF if he wants to add records at the end of an existing 
disk file. 



is attached and 
not ready, the 
him to make it 
DETACH tape 181 



Both RECFM and BLKSIZE must always be specified. The record 
fcrmat must be either V or VB. 



ACCIN 



This is the history file, normally it is a tape on tape 
drive 182. This file is used if either MERGE=Y or HIST=Y is 
specified explicitly or implicitly. (HIST=1 is implied when 
certain reports are requested) . If either MERGE=Y or HIST=Y 
is specified, tape 182 is rewound before any reading is 
dene. 



By issuing his own FILEDEF for ACCIN prior to invoking 
CPEREP, the user can override CPEREP's FILEDEF. Thus, he 
can read history data from another tape drive or from a disk 
file. However, the rewinding of tape 182 is independent of 
the user's FILEDEF and this causes two problems: (1) 
Regardless of the user's FILEDEF, CPEREP attempts to rewind 
tape 182 as long as there is a tape 182 attached to the 
virtual machine (and provided that HERGE=Y or HIST=Y) . If 
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182 is attached and ready, it is rewound; if attached but 
net ready, the operator is notified and CPEREP will wait for 
him to aake it ready. The solution to this problem is to 
DETACH tape 182 before running CPEREP. (2) The second 
problem is that CPEREP does not automatically rewind the 
user defined file (if it is another tape drive) before 
reading from it as it would for tape 182. The solution to 
this problem is for the user to issue a CMS TAPE command to 
rewind the tape prior to invoking CPEREP. 

The record format must be either V or VB. If the history 
file is on a tape, both RECFM and BLKSIZE must be specified. 



CPEREP Applications 

The following examples show CPEREP used in applications that can benefit 
an installation's operation. 

Example 1: 

When the operator receives the message telling him that the error 
recording area is 90 percent full, he may have to act quickly to dump 
the error recording area to a CPEREP accumulation tape if he is to avoid 
losing data. This dumping is referred to as the "emergency offload" 
(although CPEREP does not support the OS/VS offload program (IFCOFFLD) 
to perform this function) . In this situation, to save time and avoid 
mistakes, the operator may want to avoid entering the necessary control 
parameters from the terminal. Instead, he can have CPEREP read a file 
of control parameters that, in effect, provide an immediate offload 
facility. The file should contain the following three parameters which 
can all be put in the file on a single 80 byte record: 

SYSUM=Y ACC=Y ZERO=Y 

If the file happens to be named OFFLOAD EREPCTL, then the operator could 
achieve an "emergency off load" by typing the following line after he 
has attached a virtual tape 181 to his virtual machine: 

CPEREP OFFLOAD EREPCTL 

The captured error records on the accumulator (ACC) tape can then be 
processed later at a more convenient time. 

Example 2: 

In installations having more than one system installed, with devices 
shared between systems, it is desirable to run reports covering the 
entire installation rather than individual reports on each system. If 
the error log records from each system are accumulated on separate 
accumulation tapes, then reports covering the overall installation 
cannot be produced until the separate tapes are combined in some way. 
Onder OS/VS, this is easy since the tapes can be concatenated into a 
single input file using the OS/VS JCL. But VM/370 f s CHS has no 
corresponding facility for concatenation, so a less direct method of 
combining the data is used. One such method is to use the accumulation 
capability of CPEREP to copy input tapes one at a time to an 
accumulation output tape. For example, if you have five input tapes to 
be combined, you would run CPEREP five times with the following control 
parameters: 

HIST=Y PRINT=NO ACC=Y 
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In this way a combined set of data is built up on a sixth (output) 
tape. Or you could sake just four runs if you do not mind using one of 
the five input tapes as an output tape and adding the other four input 
tapes to it. 

The order of the input tapes and their chronological order of 
creation make no difference to the accumulation process. When reports 
are generated from an accumulation tape (or from anywhere) the reports 
are effectively sorted in the desired sequence. 

Example 3: 

At installations having shared devices, channel switches, etc., the 
SHARE parameter is used for running most reports. And a large number of 
SHARE parameters might be required in a large installation. 
Furthermore, this set of SHARE parameters would be fairly stable, 
changing only when the installation's I/O configuration changes. In 
this case it is probably worthwhile to keep the required set of SHARE 
parameters in a file by itself. The SHARE parameters in the file would 
be followed by a TERMIHAL control parameter so that the "Mixed Method" 
of entering operands could be used- The fileid of this file would be 
specified on the CPEREP command line. As a result, the SHARE parameters 
would be read from the file and then additional parameters would be 
prompted for at the terminal, allowing parameters requesting a 
particular report to be entered. 



Section 4. Additional CE Aids 97 



SET RECORD and SET MODE Facility 



SET RECORD Facility 

The CP SET command with the RECORD option is a valuable asset in the 
diagnosis of system hardware I/O problems on a System/370 controlled by 
VM/370. The SET RECORD can only be invoked by the Class F user. 

By inserting the proper operands in this command, the error recording 
area receives records that were triggered by the following items 

• Specific real I/O device address 

• Specific limit count 

• Specific sense byte data 

The importance of the SET RECORD facility is readily apparent when 
one realizes that virtual machine I/O errors are not necessarily 
recorded on the system's error recording area- If SVC 76 is invoked, 
however, the chances of the less of error records is lessened. CP 
records errors associated with its own operations; that is, spooling, 
paging, and CMS operations and so forth. Errors detected during CP 
initialized recovery attempts are not recorded by the SET RECORD option. 
It does not normally record I/O outboard errors associated with virtual 
machine operations unless it is specifically requested by a virtual 
machine invoking the SVC 76 instruction. 

Outboard I/O errors from dedicated virtual machine devices are 
reflected to the virtual machine that initiated the SIO action. It is 
that virtual machine's responsibility to initiate recovery. This may 
entail, beside retry routines, error recording on another dedicated 
device of that virtual system. It is therefore conceivable that for 
multiple virtual machines on one VM/370 system, there could be multiple 
error recording or LOGREC areas. To the CE at the central site and to 
users of the virtual system, this could present many problems. 

To circumvent the apparent problems, the CE can invoke the SET RECORD 
command. The SET RECORD command format and operands are fully described 
in the VM/370 Operator's Guide. This command allows the CE to monitor 
and record any specific unit check condition on any specified device. 
If the malfunction is sporadic in nature and there are large time lapses 
between failures, the SET RECORD command can be invoked and not 
disturbed for however long it takes to capture the quantity of errors 
desired for the device specified. If SET RECORD OFF is not entered, 
intensive recording is automatically terminated after 10 errors are 
recorded in the VM/370 error recording area for that device. SET RECORD 
values are not retained by system checkpoint activity, so if the VM/370 
system operation is suspended and then loaded again, the SET RECOBD 
command must also be reinvoked if monitoring of a specific device is to 
continue. 

The SET RECORD function is available for one I/O device at a time. 
To specify a different device, invoke the SET RECORD command again with 
the desired new operands. CP overlays the first SET RECORD request with 
the second request so that the first SET RECORD request is obliterated. 
There is no way to initiate this method of error recording on multiple 
I/O devices. 

The SET RECORD command contains a LIMIT operand. The LIMIT operand 
is the threshold value that indicates when recording is to take place. 

Sense byte data consists of a selected sense byte hit or the logic 
output of the "and" or "or" condition of two selected sense byte bits. 
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Examples of the format for employing Intensive Recording mode follow: 

S EEC ON raddr LIMIT nn BYTE nn BIT n AND BYTE nn BIT n 
SET REC ON raddr LIMIT nn BYTE nn BIT n OR BYTE nn BIT n 
SET RECORD ON LIMIT nn BYTE nn BIT n 

Sample of S^T RECORD comma ntt usage : 

z en 12" 

— or — 

set rec on 314 limit 01 byte 00 bit 7 or byte 01 bit 7 

The first sample shows that when the real device addressed as 127 has 
accumulated five errors as a result of the "and" condition of bits 4 and 
3 of sense bytes 00 and 03, respectively, the errors are recorded,. 

The second sample is similar but when this device, whose real address 
is 314, encounters a bit 7 active either in byte 00 or 01, the errors 
are recorded. 

To turn off all intensive recording, make the following entry. This 
nullifies previously issued SET RECORD option. 

Example 

SET RECORD OFF 



SET MODE Facility 

The function of the recovery facility mode switching routine is to allow 
installation support personnel to change the mode that CPU retry and ECC 
recording are operating in. This routine receives control when a user 
with class F privileges issues some form of the SET MODE command. A 
check is initially made to determine whether or not this is VM/370 
running under VM/370. If it is, then the request is ignored and control 
is returned to the calling routine. The SET MOEE command is described 
in the VM/370 Operator's Guide. 

The SET MODE command has five operands which are described as 
follows: 

The MAIN operand applies to processor storage bit failures that are 
detected and corrected by hardware logic. The SET MODI MAIN command is 
treated as invalid if issued on a 3031, 3032, or 3033 processor. 

The RETRY operand pertains to processor instruction failures that are 
CPO detected and corrected by recycling the failing instruction through 
the system logic again. 

The QUIET operand causes the specified facility (MAIN or RETRY) to be 
placed in quiet mode, in order to preclude the recording of errors. 

The RECORD operand causes the count of soft errors to be reset to 
zero and the specified facility to be placed in record mode; this is the 
mode in which CPO retry and/or ECC errors are recorded. 



Section 4. Additional CE Aids 99 



The CPDID operand is an optional selection operand effective only for 
the attached processor mode of operation of VH/370. The CPDID operand 
allows the user to apply the previously specified operands to either the 
attached processor or the main processor. If CFUID is not specified en 
the command line, then the applicable MAIN, RETRY, QUIET, and RECORD 
operands apply to both processors. 

The error recording of instructions that are retry-corrected or 
ECC-corrected storage errors is determined by the setting of control 
register 14 bit 4. 

ON = RECORD MODE 
OFF = QUIET MODE 

The initial setting is a function of processor design (that is, the 
system reset can either initialize soft recording or not) ; afterwards, 
soft recording can be invoked only by the SET MODE command. Suspension 
of soft recording can be achieved by arriving at the threshold count or 
by invoking the SET MODE QUIET option. Note that the status of record 
mode is retained by VM/370 through "warm" and "cold" start procedures 
(system abend conditions) . For more details on soft recording, refer to 
the topic "Recovery Modes" in Section 2. 
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Trace Facilities 



CP's TRACE Command 

Tie CP TRACE facility of Vtt/370 is a powerful tool that can assist the 
CE in problem diagnosis. By the use of this command, a printout cf 
designated program activity can be obtained. This command belongs to 
the G privilege class and can be employed by the general user as an aid 
in program fault analysis. 

The command is flexible to the extent that a program trace can be 
obtained for a particular machine operation or a mix cf system machine 
operations comprising seme or all of the following: 

SVC interrupts 

I/O interrupts 

Program interrupts 

External interrupts 

Privileged, Branch, or All instructions 

Channel instructions and related activity 

CSfls 

The format and operands of the TRACE command are described in the 
VIS/370 CP Command Reference for General Users. 

Certain functions provided by TRACE operands are obviously useful to 
the CE,. For example, SIO or CSW with the I/O interrupt operand; both 
indicate the real device address with which I/O operation was involved. 

In using the TRACE command, output data is printed on the CE*s 
virtual machine console if the PRINTER option is not invoked. The CE's 
terminal (the default output device) is specified by the BOTH operand or 
by invoking the TERMINAL operand,. Thus, in the course of using TRACE, 
the printer output device is altered. The PRINTER operand refers to the 
virtual high speed printer. The file for the PRINTER containing the 
TRACE activity is relayed to the real spooling printer after the CLOSE 
command is invoked to close or signify the end of that file. 

TRACE activity, optioned to the printer directly or indirectly by 
invoking the SPOOL CONSOLE command, is transmitted to a remote printer 
by utilizing the facilities of RSCS. Remote spooling procedures are 
described in the VM/ 370 RSCS Use r's Guid e. 

In operation, after invoking the TRACE command, the TRACE operaticn 
halts the program being traced after executing the first encountered 
condition specified by the TRACE operands. To initiate the program 
again and resume TRACE activity, the CE must issue the EEGIN command. 

Before resuming TRACE execution, the virtual machine user can alter 
the previously imposed trace facilities. This procedure is described in 
the following text. 

Assume a program is loaded in the virtual CPU. The virtual system 
then enters console function mode prior to program execution. The TRACE 
command function is now used with the ALL option and the BEGIN command 
is invoked. The ALL option allows instruction tracing among other 
things. Therefore, the virtual system after startup again enters 
console function mode after the printout cf the first executed 
instruction. Assume now, that it has been decided not to record all 
facilities of the TRACE command, and that SVC, I/O, and program 
interruption tracings are to be eliminated. These interrupt conditions 
are now entered with the TRACE command and the OFF option. BEGIN is 
again issued, and the subsequent TRACE table no longer contains these 
interrupt entries. 
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The TRACE command then has the flexibility of accepting multiple cr 
single additions or deletions of operands. 

After the next printout at the terminal, execution of the program is 
again halted in console function mode. An examination discloses that 
the trace facilities are satisfactory, the TRACE command is then invoked 
with the RON option. Now, the program, after executing another BEGIN, 
runs to the completion, printing out trace data without any BEGIN 
intervention. If, however, the program is looping, or if the user wants 
to suspend tracing activity, he signals CP by means of an attention 
interrupt, then enters: 

trace end 

Examples of invoking TRACE are: 

trace svc 

trace all 

trace svc program i/o both run 

tr program off 

tr end 

tr ccw printer 

To summarize, the TRACE command allows tracing SVC, I/O, program and 
external interrupt conditions as well as SIO, privileged instructions, 
CCW, branch instructions, all instructions or all of the above. 

Trace facilities can either be turned on or off. Trace printout can 
be optioned to the user's terminal or the spool virtual printer or both. 
Using the facilities of RSCS, trace output can be spooled to a remote 
printer. 

The TRACE command executed on the user's terminal defaults to the 
NORDN condition (stops after each trace print line) unless the RON 
option is specified. 

For a printout of a trace operation where the virtual printer was 
used as the output device, the CLOSE PRINTER command must be executed. 

N otes : 

1. A branch to the next seguential address or to the same address is 
not identified in the trace table. 

2. Erroneous branch I/O, or instruction-tracing results can be 
obtained when TRACE encounters instructions that examine or modify 
the next two successive bytes of the following instruction. 

3. I/O operations for virtual channel-to-channel adapters, with both 
ends connected to the same virtual machine, cannot be traced. 

Figure 34 shows trace data invoked by applying the CP TRACE command 
with the following options: 

trace sic ccw i/o csw printer 

The PRINTER operand directs the trace data file to print out on the 
system's spooling printer. 
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I ' 

! I/O 001196 SIO 9C002000 CONS 0009 CC 1 

*** 001AEE I/O 0009 ==> 001AB2 CSW 0800 

I/O 001A96 SIO 90002000 DASD 0191 CC DASD 0331 CAW 00003560 

CCW 003560 07003314 40000006 07AA38 0707AA80 40100006 

« SEEK 00000000 000004 SEEK 0000017F C000 

CCW 003568 290033T0 600GG0G4 07AA40 29056310 6G8CCC04 

CCW 003570 08003568 00000000 07AA48 0807AA40 2910000C 

CCW 003578 060036E0 20000050 07X150' 060566E0 20800050 

*** 001AEE I/O 0009 ==> 001AB2 CSW 0400 

CSW V 0191 00003570 0E000004 E 0331 0007AA48 0E000004 

*** 001AEE I/O 0191 ==> 001AB2 CSW 0E00 



Figure 34. Segment of a Trace Printout of a Program's I/O Operation 

See the TRACE command and the complete listing of the printout 
message formats available with this command in the VH/370 CP Command 
Inference for General Osers.. 

Note: If the virtual machine assist feature is enabled on your virtual 
machine, CP turns it off while tracing SVC and program interruptions 
(SVC, PRIV, BRANCH, INSTRUCT, or ALL} . After the tracing is terminated 
with the TRACE END command line, CP turns the assist feature on again. 

If the virtual machine is running virtual=real (V=R) with NOTRANS ON, 
CP forces CCW translation while tracing SIOs or CCWs. After tracing is 
terminated with TRACE END, CCW translation is bypassed again. 



NETWORK TRACE 

VM/370 provides a means of capturing the basic transmission unit (BTO) 
header and data information pertaining to a particular 3704/3705 line 
resource. This is accomplished by invoking the NETWORK TRACE command. 
NETWORK TRACE is effective only if the 3704/3705 communications 
controller is loaded with either the network control program (NCP) or 
the partitioned emulation program (PEP). NETWORK TRACE is not effective 
for 3704/3705 devices loaded with the 270x emulation program (EP) . This 
CP command can only be invoked by the privilege class E user. 

For information concerning the header and other related information 
concerning the 3704 and 3705 operations, consult the publication IBB 
3704 and 3705 Communications Control Network Control Program Generation 
and Utilities Guide and Reference Manual (for OS/VS TCAH users). Order 
NO. GC30-3007. 

For information on how this command is used, see the NETWORK command 
description in the VM/370 Operators Guide. 



RSCS Logging 

The remote spooling communications subsystem (RSCS) has the ability to 
log all I/O activity en a particular teleprocessing line. Normally, 
such logging is not needed but, if a problem exists that requires 
tracing I/O on a line, logging can be turned on. The RSCS virtual 
machine operator turns it on and off by issuing the privilege class G 
command, CMD, with the LOG or NOLOG operand. 
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To start the logging operation, the RSCS operator issues CHD, then 
enters the 1 to 8 character link identifier of the remote station 
associated with the link, followed by the keyword, LOG. LOG starts the 
logging of I/O activity on the line and NCLOG stops the logging 
operation. The format and operands of CMD are described in the VH/370 
Remote Spooling Communications Subsystem (RSCS) Oser's Guide. 

The output of the logging is a printer spool file containing a 
one-line record for each I/O transaction on the line; for example, each 
time a teleprocessing buffer is written into or read out of. 

When logging is turned off (NOLOG) the output is printed. The 
distribution code on the printer output is the linkid for which logging 
was being dene. 

The contents of the log record in order of occurrence from left to 
right are as follows: 

21 bytes The first 21 bytes of the log record are the first 

21 bytes of the teleprocessing fcuffer, including 
BSC bytes, HULTI-LEAVING* bytes (for SHL only), 
and enough initial data bytes to fill the field,. 

7 bytes Read I/O Last seven bytes of the CSU. 

SHL Write First seven bytes of SHL buffer (the buffer header 
I/O used internally by SHL but not transmitted) . 

NPT Write Not applicable. 
I/O 

3 bytes RSCS I/O synch lock for this I/O operation. 

1 byte These bytes are the sense bytes (if any) . 

8 byte CCW associated with the I/O operation 

The fields of the record are separated by blanks. Figure 35 shows 
the read and write leg records for SHL. 



^Trademark of IBH 
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SAMPLES OF READ AND HRITE RECORDS FOR SHL 



1070 

1070 

1002808FCF9094000026 

1002818FCFA0940000 

1 00281 8FCF9491C140009483C140009483C 1400 094 

1070 

1002828FCF9483C8C6C9D3C57A40C4E787C4C5E7C5 

323D 

1002828FCF9483E4C4C5E2E37A40C8D6E2E3D3C9D5 

1070 

1002838FCF9481CC50D5E4D4C2C5D9407E4050F100 

1C70 

1002848FCF9481FF5C5C5C40C3C1E4E2C5E240E3C8 

1070 

1002858FCF9481C7C3D740D84007C6009481E350E3 

1070 



21 BSC, MOLTILEAVING AND DATA BYTES 



0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
0779C 
V. 

SHL 



8CC00018E 
8CC00018E 
80C000186 
8CC000186 
8CC00003C 
80C00CG3C 
80E0G0190 
80E00005C 
80E00005C 
8CC0C000C 
80C0000CC 
80C000008 
8CC0000C8 
8CC0000C3 
80C0000C3 
80C0000I7 
8CCO00OE7 
^^ ; 

INTERNAL 
EOFFER 
- OR - 



8C0000 00 

000000 00 

800000 00 

8C0000 00 

8CC000 00 



Ol/UUUU 

8C00C0 
8CC000 
0C0000 
800000 

ocoooo 

8C00C0 
OCOOOO 
8C00C0 
OCOOOO 
8C0000 
000000 



01 
02 
00 
00 
00 
00 
00 
00 
00 
00 
00 



0207100720000190 
0107100760000002 
0207100720000190 
0107100760000009 
C207100720000190 
n-j f)71 1 ovcnnnnflno 



02071 
02071 
01071 
02071 
01071 
02071 
01071 
02071 
01071 
02071 
01071 
v 



19F20000190 
19F20000190 
19F60000002 
19F20000190 
00760000002 
00720000190 
19F60000002 
19F20000190 
00760000002 
00720000190 
19F60000002 



SYNCH SENSE 
LOCK BYTE 



CCW 



TP BUFFER 



ADDR STATUS CCONT 
EYTES 



CSH 



liqure 35, Read and Write Log Records for SHL, 
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VMFDUMP 



Systei abend (abnormal ending) conditions can be prompted by real 
System/370 system operator intervention involving PSW restart. System 
abend conditions can also be caused by program SVC operation. This 
may happen when CP is in a program predicament which it cannot correct 
and therefore cannot validly continue processing. SVC may also occur 
when the CP system recognizes a catastrophic situation that was prompted 
by a hardware malfunction- 
When such situations occur, SVC invokes a system dump. The dump 
operation prompted by the main processor (or attached processor, if 
applicable) captures the system registers and defined storage areas and 
may or may net contain a trace table with the sequence of events that 
occurred just before the condition that caused the abnormal ending. 
This trace table data appears in dump output if the CP MONITOR command 
with the STOP operand was not invoked before the dump operation. 
Consult the VM/370 Sjrstem Programmer's Guide for details of the CP 
MONITOR command and CP's internal trace facility. The selection of such 
options can expedite system recovery. 

Note: The internal trace facility should not be confused with the CP 
TRACE command functions. 

Facilities also exist within CP to allow the automatic spooling of 
abend dump files onto DASD devices (if so desired) by a CP SET command 
option. 

During the interval between the malfunction and the resumption of 
system activity, logout or error recording may also have taken place. 
The system dump file (previously spooled to a LASD device) can then be 
processed and formatted by the VMFDUMP command. This command extracts 
data pertinent to the type of abend and creates a problem report. It 
also prompts the user for additional information that describes the 
problem. The VMFDOMP command is described fully in the VM/370 
In ter ac tive Problem Control Sjrstem (IPCS) User's Guide and the VM/370 
Operator's Guide. 

The extent of system abend and VMFDUMP utilization is controlled by 
the system operator and cannot be invoked by the CE. 

Data concerning hardware status, sense, and I/O operation is in the 
RDEVBLOK, IOBLOK, and IOERBLOK control blocks. 

The RDEVBLOK and IOBLOK illustrations are given in figures 9 and 10 
in section 3 under "I/O Error Recovery — Detailed Description." 

The information in these blocks, in conjunction with program support 
personnel or customer program personnel, may assist the CE in defining 
the cause of the system fault or aid in reconstructing the sequence that 
prompted the system fault. Basically, the full formatted dump produces 
the results discussed below. 

1. The header contains the time and date of the abend as well as an 
abend cede and the processor identity that initiated the dump 
operation. 

2. This is followed by PSWs, CAW, CSW, the time-of-day clock, the 
clock comparator, the prefix register, the processor and interval 
timer values of the processor that caused the abend. 
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3. This step applies to attached processor operations only: Next the 
PSA (prefix storage area) of the main processor is printed followed 
by the PSA values for the attached processor if the system was in 
attached processor mode when the abend occurred. 

4. Following this is data extracted from CP's symbol table (DHKSYH) , 
which contains the storage location of selected entry points for 
the CP system. 

5. The tabulations that follow the symbol table printout are pages 
that are applicable to the real system hardware. These blocks 
represent every channel, every control unit, and every device that 
is represented as available to VM/370 operations. These blocks are 
designated as RCHBLOK, RCUBLOK, and RDEVELOK, respectively. Those 
devices that are actively involved with system operations at the 
occurrence of system abnormal ending are indicated by an adjacent 
display of an active IOBLOK. 

6. These blocks are followed by statistics applicable to the spool 
files that are applied to the spooling devices (system reader, 
printer, and punch). These blocks are designated as spooled file 
blocks (SFBLOK) . If no spooling activity exists, then the VHFDUBP 
output indicates this (as indicated in the following VMFDUEE 
sample) . 

7. The spooled file data is followed by the CORTAELE. This table 
indicates the real address of the four doubleword entries that 
contain pointers to the SWPTABLE, the PAGTJELE, the previous entry 
in queue, and the next entry in queue. Also contained in this block 
are flags to indicate whether the page is on the flush list, the 
free list, or is shared or unavailable. The CORTAELE printout also 
indicates the user identity and the page assignment at the time cf 
the abnormal ending. 

8. After the CORTABLE, there is a progression of data blocks that are 
related to each logged on user. They are listed in the following 
order: the virtual machine blocks (VMBLOCK) , virtual channel blocks 
(VCHBLOK) , virtual control unit blocks (VCOBLOK) , virtual device 
blocks (VDEVBLOK) , and virtual console control blocks (VCONCTL) . 
This is followed by Segment tables. Page tables and Swap tables 
(SEGTABLE, PAGTABLE, SWPTABLE), respectively that are applicable to 

the associated user's virtual machine activity. 

Figure 36 illustrates the output of a formatted vMFDOMP operation 
(uniprocessor mode) . 
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VM/370 SYSTEM ABEND CODE PRG05I DATE 09/08/72 



TIME 15!13:31 



GRECS 0-7 
•-15 



CREGS 0-7 
8-15 



00000034 00C5C1C4 00000048 0007BC10 00000000 000237F8 
0002370E 0007B668 00000000 00033448 00023480 00073A08 



808008C0 00026F80 FFFFFFFF FFFFFFFF 00000000 OOOQOOOO 
00000000 00000000 00000000 00000000 00000000 00000000 



FPfiGS 0-4 00000000 00000000 00000000 00000000 00000000 00000000 

TOO CLOCK 82636C06 45506000 TOD CLOCK COUP 8263E1B3 57000000 

CPU TWER FFFFFFFF CA337000 

CSM 00000000 00000000 CAM 000158DO 

EXT OLD PSH 1004 07000000 00015A56 

SVC OLO PSN 0008 OOOCOOOO 000002 3E 

PGM OLO PSH 0005 OOOCOOOO 00023812 

MCK OLO PSH 00000000 00000000 

I/O OLO PSH 0046 07000000 0001764A 



00000000 00000008 
00012D22 00072390 



00000000 00000000 
EFCOOOOC 00073930 



00000000 00000000 



INT TIMER OOOOOEOO 
EXT NEW PSH 
SVC NEW PSH 
PGM NEH PSH 
MCK NEH PSH 
I/O NEH PSH 



OOOCOOOO 000009C8 

OOOCOOOO 00000500 

OOOCOOOO 000 11C 5 8 

00080000 00011000 

OOOCOOOO 00014080 



DMKPSA 


- 


000000 


ONKPSASV 


- 


000500 


DMKPSANS 


- 


000 B44 


OMKPSADU 


- 00069C 


OHKPSAEX 


- 


0009C8 


OHKPEIM 


- 


000560 


OMKPSARX 


- 


00081A 


DMKPSAID 


- 


000850 


DMKPSARS 


- 000860 


DMKPSARR 


- 


000866 


DMKMCH 


- 


011000 


DMKPRG 


- 


011C58 


OMKPRGCT 


- 


011D30 


OMKPRV 


- 012120 


OMKPRVCT 


- 


012178 


DMKPRVL6 


- 


012120 


DHKPRVKV 


- 


0127A8 


DHKHVC 


- 


012998 


OMKHVCAL 


- 012998 


DMKHVCYL 


- 


012EA0 


OMKHVCPC 


- 


012EA8 


DMKGEN 


- 


012FD8 


DMKDGD 


- 


0130E0 


DMKVAT 


- 013608 


OMKTMR 


- 


013E10 


OMKIOS 


- 


014020 


OMKIOSOR 


- 


014020 


DMKIOSOV 


- 


01402C 


DMKIOSIN 


- 014080 


OMKIOSRW 


- 


0147AA 


DMKIOSCT 


- 


01421C 


OMKRIO 


- 


019558 


DMKRIOOV 


- 


019558 


DMKRIOCU 


- 01BF08 


DMKRrOCH 


- 


01C398 


OHKRIOCT 


- 


01C518 


ONKRIOCC 


- 


01C538 


OMKRIOUC 


- 


01C53A 


DMKRIOOC 


- 01C53C 


OMKRIOCN 


- 


01C540 


OHKRIOPR 


- 


01C548 


ONKRIOPU 


- 


01C554 


OMKRIORD 


- 


01C55C 


OMKCNS 


- 014A88 


DMKCNSIN 


- 


014A88 


DMKCNSID 


- 


014E2E 


DMKCNSOF 


- 


014FE8 


DMKTBL 


- 


015C88 


OMKRSP 


- 016788 


OMKRSPEX 


- 


016788 


ONKRSPHO 


- 


017920 


DMKRSPID 


- 


017950 


DMKRSPOL 


- 


017948 


DMKRSPRO 


- 017940 


OMKRSPPR 


- 


017930 


DMKRSPPU 


- 


017938 


OMKRSPAC 


- 


017928 


DMKRSPER 


- 


017954 


DHKDAS 


- 017A00 


OMK I0E 


- 


018AB8 


DMKCCH 


- 


019098 


OMKSTK 


- 


01C568 


OMKSTKCP 


- 


01C568 


DMKSTKIO 


- 01C586 


DMKDSP 


- 


01C5B0 


OMKOSPCH 


- 


01C5B0 


OMKDSPQS 


- 


01CF08 


OMKOSPRQ 


- 


OICFOC 


OMKDS PA 


- C1C504 


OMKOSPB 


- 


01C5F8 


ONKOSPNP 


- 


01CF1C 


DHKDSPCC 


- 


01CF20 


OMKDSPAC 


- 


01CF24 


OMKDSPBC 


- 01CF28 


DMKSCH 


- 


010008 


0MKSCHN1 


- 


01D7D0 


DMKSCHN2 


- 


0107DC 


OMKSCHCT 


- 


0100CO 


OMKSCHPU 


- 0107E0 


OMKVIO 


- 


010838 


DMKVIOEX 


- 


010838 


DMKVIOIN 


- 


010ED2 


DMKVIOMK 


- 


01E2A4 


OMKVIOCT 


- 01E29C 


DMKVIOCH 


- 


01E2A0 


DMKCCH 


- 


01E488 


DMKCCH TR 


- 


01E488 


OMKUNT 


- 


OIF SAO 


DMKUNTRN 


- 01F5A0 


DMKUNTFR 


- 


01F5F2 


ONKUNTRS 


- 


01F886 


DMKVSP 


- 


01F9A8 


OMKVSPEX 


- 


01F9A8 


DNKVSPCR 


- OlFOCA 


DMKVSPCO 


- 


02033C 



Figure 36. Formatted VMFDUMP (Part 1 of 6) 
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KiriDLUIV 

CHAN OXX 
AOOR 01C398 



020 FFFFOOOO FFFF0040 0080FFFF OOCOFFFF 0100FFFF 0140FFFF 0180FFFF 01C0FFFF 
040 0200FFFF FFFFFFFF FFFF C FFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 



000 00080000 00000000 00018FD8 0001BF08 0C01C398 00000000 00000000 00000000 
020 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 005000AO COFOC140 



ADDR 01BFD8 



ROEVBLOK 000 OOOCOOOO 00022082 000195A8 000195A8 0001BFD8 OOOOOOCO CCOOCOOO 00000000 
OEV OOC 020 000000C2 00000000 000248E8 OOOCOOOO 40404040 4040000C COOOOOOO 00000000 
AOOR 0195A8 040 OOCOOOOO 00000000 10000000 OOOOOOOC 



ROEVBLOK 
OEV 000 
ADOR 0195F8 



000 00000000 00021082 000195F8 000195F8 0001BFD8 00000000 OOOCOOOO C3C 10000 
020 00000010 OOOCOOOO 000248E8 OOOCOOOO 40404040 40400000 00000000 00000000 
040 00000000 00000000 00000000 00000000 



ROEVBLOK 
OEV OOE 
ADDR 019648 



000 OOOEOOOO 00031041 00019648 00019648 0001BFD8 OOOOOCOO 00000000 C1404040 
020 00COQ5CA 00000000 C00248E8 00000000 40404C40 40400000 00000000 00000000 
040 00000000 00000001 OOOCOOOO 00000000 



ROEVBLOK 
OEV OOF 
AOOR 019698 



000 OOCI-0000 Oo03iC4i 00019698 00019698 OOOiBFOo COOOCOCC OOOOOOCO £2404040 
020 00000077 00000000 000248E8 00000000 40404040 40400000 00000000 OOOCOOOO 
040 OOOOOCOO 00C0C001 00000000 COOOOOOO 



RCU8L0K 
UNIT 01X 
ADDR 01C018 



000 00180000 00000000 0001C018 0001C018 0001C398 00000000 OOOOCOOO 00000000 
020 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFCOOO 



ROEVBLOK 
DEV OIF 
ADDR 019558 



000 OOOFOOOO OOOC8000 00019558 0C019558 0001CC18 00000000 OOOCOOOO 00000000 
020 000001C2 00000000 00025260 00090000 40404040 40400000 7B4A7C7F 82000000 
040 00000000 OOCOOOOO COOOOOOO OOOOOOOC 



RCUBLOK 
UNIT 02X 
ADDR 01C058 



000 00200000 COOOOOOO 0001C058 0001C058 0001C398 00000000 00000000 OOOOOOOC 
020 019001E0 02300280 02D00320 037003C0 04100460 04B00500 055005A0 &5F00640 



ROEVBLOK 
OEV 020 
ADDR 0196E8 



000 OOCOOOOO 80888020 0C0196E8 000196E8 0001C058 00000000 COOOCOOC 00000000 
020 00000002 0C074230 000248E8 OOCOOOOO 40404040 40400CCO 7B4A7C7F 82000000 
040 COOOOOOO 00001004 00000000 OOOOOOOC 



ACTIVE I08LOK 
ADDR 074230 



000 00208000 00074230 0001CFOC 0001CFCC OOOOOCOO OOCOOOOO 000248E8 00C14E2E 
C20 00015850 00000000 00062278 0C000001 00000000 00000000 00000000 00000000 



RCHBLOK 000 02000000 0040C000 0001C458 0001C458 00000000 OCOOOOOO OOOOOOOC OOOOOCOO 

CHAN 2XX 020 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 0280FFFF FFFFFFFF FFFFFFFF 
ADDR 01C458 040 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 02C0FFFF FFFFFFFF FFFFFFFF 



RCUBLOK 
UNIT 25X 
ADDR 01C258 



OCO 00500000 20000000 0001C258 0001C258 0001C458 00000000 OOCOOOOO 00000300 
020 226022B0 23002350 23A023FO 24402490 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 



ROEVBLOK 000 COOOOOOO 20000410 0001B7B8 0001B7B8 0001C258 00000000 00000000 00000000 
DEV 250 020 00000000 00000000 000248E8 00000000 40404040 4040C000 00000000 00000000 
AODR 01B7B8 040 COOOOOOO 00000000 00000000 00000000 



RCUBLOK 000 OODOOOOO COOOOOOO 0001C298 0001C298 0001C458 00000000 OOCOOOOO OOCOOOOO 

UNIT 2DX 020 24E02530 2580FFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 
ADDR 01C298 



ROEVBLOK 
OEV 2D0 



000 00000000 00700402 0001BA33 0001BA38 0001C298 00000000 00000000 OOOOOOOC 
020 00C0EA27 00000000 000740BO 00000000 C307C4D9 D4F 10000 OOC795A0 OOOCOOOO 



AODR 01BA38 040 0001BA38 OOOOOOOC 00000000 00000000 



RECBLOK -PAGE 000" 0007B890 00291318 FFFFEOFF FFFFFFFF 
AODR 0795A0 



RECBLOK -PAGE 000 C0008318 00421718 FFOFFFFF FFFFFFFF 
ADDR 078890 



Figure 36. Foriatted VMFDUMP (Part 2 of 6) 
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WINTER SPOOL CHAIN 

NO SFBLOKS ON THIS CHAIN 
PUNCH SPOOL CHAIN 

NO SFBLOKS ON THIS CHAIN 
READER SPOOL CHAIN 



SFBLOK 
BOBBIE 
ADOR 0743C8 



000 00074428 00CB0F01 C2D6C2C2 C9C54040 C2D6C2C2 C9C54040 O0000A2B 0050003B 
020 0182000A 00000000 D3C4E340 40404040 404040E2 E3C1D9E3 C1C40940 40404040 
040 F0F961F0 F761F7F2 F0F97AF3 F97AF5F3 00CA1E01 0001C100 00000000 OCOOOOOO 



SFBLOK 000 000744E8 00C72E01 C2D6C2C2 C9C54C40 C304E2C2 C1E3C3C8 00000010 00500054 

B08BIE 020 00S20Q0Q OOOQOOOO C4D4E2C9 D5D44C4C 4C4C40E3 C5E7E340 40404040 4C40404C 

AOOR 07442B 040 F0F961F0 F761F7F2 F1F07AFO F97AF0F6 00C72E01 0001C100 OOCOOOCO 00000000 

SFBLOK OOC 00074548 00CA3801 C406E6D5 E2404040 C406E605 E2494040 00000A3A 005C018E 

DOWNS 020 0182C00A OOOCOOOO D3C4E340 4040404C 404040E2 E3C1D9E3 C1C40940 40404040 

AOOR 0744E8 040 F0F961FO F861F7F2 F0F97AF2 F87AF5F6 OOC70901 0001C100 OOCOOOOO 00000000 

SFBLOK 000 000745A8 OOCD0401 C304E2C2 C1E3C3C8 D106C8D5 E7404040 OOOCOOCB 005001A8 

CMSBATCH 020 88820000 000107E0 C4D4E2C3 C9E34040 404040D1 06C24040 40404040 404C4040 

ADDR 074548 040 F0F961FC F861F7F2 F1F07AF4 F87AF1F6 00CD0401 0001C100 00000000 OOOOCOOO 
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TABLE 


*••**•*** 


PAG 


USE 


R I D 


024A58 
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02073C38 


00073008 
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024A68 


0C0223D8 
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00073252 
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024A78 
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CP- 


PAGEABLE 


024A88 
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CP- 
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024A98 
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82073208 


0007319C 


004 
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C24AA8 
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82073278 


00073248 
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CP- 
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024AB8 


00022308 
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82073338 


00073308 
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PAGEABLE 


024AC8 


00022308 
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820731F8 


00073198 
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C24A08 
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CP- 


FREE STORAGE 


024AE8 


00022308 


0000006E 


82073350 


0007330E 
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CP- 


PAGEABLE 


024AF8 


C609C5C5 


000223C8 
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OOOOOOOO 


00 A 
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FREE STORAGE 


024B08 


C6D9C5C5 


000223C8 


02077E38 


00000000 


OOB 


CP- 


FREE STORAGE 


024B18 


00022308 
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82073340 


C007330A 


OOC 


CP- 
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024B28 


00022308 
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82073288 


0007324C 
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CP- 
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024B38 


C609C5C5 


000223C8 


02078070 


OOOOOOOO 


OCE 


CP- 


FREE STORAGE 


C24B48 


C609C5C5 


00C223C8 


02078FE8 


OOOOOOCO 


OOF 


CP- 


FREE STORAGE 


024B58 


C6D9C5C5 


00C223C8 


02078830 
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010 


CP- 


FREE STORAGE 


024B68 


5CC3075C 


00000000 


0207310C 


C00730CA 


Oil 


CP- 


RESIDENT 


024B78 


5CC3D75C 


00000000 


02073108 


000730CC 


012 


CP- 


RESIDENT 


024688 


5CC3075C 


00000000 


02073110 


000730CE 


013 


CP- 


RESIDENT 


024B98 


5CC3D75C 


cooooooo 


02073118 


00073000 


014 


CP- 


RESIDENT 


024BA8 


5CC3075C 


00000000 


02073120 


00073002 


015 


CP- 


RESIDENT 


024BB8 


5CC3075C 


00000000 


02C73128 


00073004 


016 


CP- 


RESIDENT 


C24BC8 


5CC3075C 


OCOOOOOO 


02073130 


00073006 


017 


CP- 


RESIDENT 


024BD8 


5CC3D75C 


00000000 


02073138 


000730D8 


018 


CP- 


RESIDENT 


0248E8 


5CC3075C 


00000000 


02073140 


0007300A 


019 


CP- 


RESIDENT 


024BF8 


5CC3D75C 


COOOOOOO 


02073148 


0007300C 


01A 


CP- 


RESIDENT 


024C08 


5CC3075C 


00000000 


02073150 


000730DE 


01B 


CP- 


RESIDENT 


C24C18 


5CC3D75C 


00000000 


02073158 


C00730E0 


01C 


CP- 


RESIDENT 


024C28 


5CC3D75C 


00000000 


0207316C 


000730E2 


01 D 


CP- 


RESIOENT 


024C38 


5CC3D75C 


00000000 


02073168 


000730E4 


01E 


CP- 
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024C48 


5CC3075C 


00000000 


02073170 


000730E6 


OIF 


CP- 
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024C58 


5CC3075C 


00000000 


020731B8 


00073188 
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CP- 
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024C68 
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00000000 
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0007318A 
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CP- 
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00000000 
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CP- 
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024C88 
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00000000 


O2O731D0 


0007318E 


023 


CP- 
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5CC3075C 


00000000 
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00073190 
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CP- 
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024CA8 


5CC3D75C 


00000000 


020731E0 
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CP- 
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VHBLOK 
USER SrSTEN 
AODf) 0248E8 



OOO 00000000 
020 00000000 
040 FFFFFFFF 
060 00000000 
080 FFFFFFFF 
GAO 00020000 
OCO 00000000 
OEO 00000000 
100 000 00000 
120 00000372" 
140 40404040 
160 00000000 



OOOOCOOO 
00000000 
FFFFFFFF 
FFFFFOFF 
FFFFFFFF 
00000000 
00000000 
00000000 
00000000 

owowce 

40404040 
00000000 



00059A48 
00000000 
FFFFFFFF 
FFFFFFFF 
COOOOOOO 
OOOOOCOO 
OOCOOOOO 
00000000 
E2E8E2E3 
00000008" 
00000000 
00000000 



ocoooooo 

00000000 
FFFFFFFF 
FFFFFFFF 
00000000 
00000000 
00000000 
00000000 
C5D44040 

xrotooooo 

00000000 
00000000 



00026F80 
FFFFFFFF 
D6400080 
FFFFFFFF 
OOOOOOOO 
OOOOOOOO 
OOOOOOOO 
OOOOOOOO 
FOFOFOFO 
OOOOOOOO" 
OOOOOOOO 



00088000 COOOOOOO 
FFFFFFFF FFFFFFFF 
00010000 OOOOOOOO 
FFFFFFFF FFFFFF05 
OOOOOOOO OOOOOOOO 
OOOOOOOO OOOOOOOO 
OOOOOOOO OOOOOOOO 
OOOOOOOO OOOOOOOO 
FOFOFOFO 40404040 
00 00O O--OOOO0OW 
F2C70000 OOOOOOOO 



OOOOOOOO 
FFFFFFFF 
OOOOOOOO 
2526B000 
OOOOOOOO 
OOOOOOOO 
OOOOOOOO 
OOOOOOOO 
40404040 
OOOOOOOO 
OOOOOOOO 



SEGTABLE 


PAGTABLE 


S H P T 


ABLE 


00 F0073008 





0000 


45000000 


0C040101 




1 


0010 


45010000 


0OC402O1 




2 


0020 


45020COO 


0C040301 




3 


003C 


45030000 


00040401 




4 


0040 


45040000 


00040501 




5 


0050 


45C50000 


00040601 




6 


0060 


45060C00 


00040701 




7 


0070 


45070000 


00040801 




8 


0080 


45080000 


00040901 




9 


0090 


45090000 


00040A01 




A 


00 AO 


450AOO00 


00040B01 




B 


00 BO 


450B0000 


00040C01 




C 


OGCO 


450COOOO 


00040001 







00 DO 


45000000 


00040E01 




E 


OOFO 


450E0000 


00040F01 




F 


OOFO 


450F0000 


00041001 


01 F00730C8 





0100 


45000000 


00041101 




1 


0110 


45010000 


000412C1 




2 


0120 


45020000 


00041301 




3 


0130 


45030000 


00041401 




4 


014C 


45040000 


00041501 




5 


0150 


45050000 


0C041601 




6 


01 6C 


45060000 


00041701 




7 


0170 


45070000 


00041801 




8 


0180 


45080000 


00041901 




9 


0190 


450900C0 


00041A01 




A 


01A0 


450A0000 


00041 BO 1 




B 


01B0 


450B0C00 


00041C01 




C 


01CC 


450COCOO 


00041001 







0100 


45000000 


00041E01 




E 


01E0 


450EOC0C 


00041F01 




F 


01 FO 


450FOOOO 


00042001 


02 F0073188 





0200 


45000000 


00042101 




1 


021C 


45010000 


00042201 




2 


0220 


4502000C 


00042301 



09 00000001 NO PAGTABLE ENTRIES FOR THIS SEGMENT 



Figure 36. Formatted YHFDOKP (Part 4 of 6) 
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VMBLCK 
USER V145D 
ADDR 059A48 



OOO 82636538 
020 00033970 
040 FFFFFFFF 
060 00000000 
080 FFFFFFFF 
OAO 0002C000 
CCO OCOOOOOO 
OEO 00000000 
100 00000000 
120 OOOOOOOF 
140 E203C5C5 
160 OOOOOOCO 



97A4F000 
0C01A318 
FFFFFFFF 
FFFFFFOO 
FFFFFFFF 
00000000 
00000000 
00000000 
00000000 
00000000 
07404040 
00000000 



00C33448 
00030007 
FFFFFFFF 
FFFFFFFF 
00000000 
OOOCOOOO 
00000000 
00000000 
E5F1F4F5 
00000028 
82636400 
OOOOOCOC 



000598E0 
OOOEOOOO 
FFFFFFFF 
FFFFFFFF 
00000000 
00000000 
00000000 
00000000 
C4404C40 
00000000 
00000000 
00000000 



00059980 
00000026 
80000000 
FFFFFFFF 
OCOOOOOO 
OCOOOOOO 
00000000 
00000000 
F7F5F860 
OOOOOOOC 
0000001F 



00080000 
0050FFFF 
4000000C 
FFFFFFFF 
00000032 
00000000 
00000000 
.00000000 
F6F7F6F4 
OOOCOOOO 
OOOCOOOO 



00059900 
FFFFFFFF 
004A4000 
FFFFFFFF 
00000000 
OCOOOOOO 

ooooocoo 

00000000 
F2F74040 
00000000 
0000A240 



00033858 
FFFFFFFF 
OOOOOCOO 
A09D8COO 
OOOOOCOO 
OOOCOOOO 
00000000 
00000000 
40404040 
OOOOOOCO 
00000000 



VCHBLOK 
CHAN OXX 
ADDR 0599D0 



000 OOOOOCOO 00000000 COOOOOFO FFFF0028 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 
020 FFFFFFFF FFFFQ05Q 



VCUBLOK 000 00000000 COOOOOOO FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 

UNIT OOX 020 00380070 00A8FFFF 
ADDR 033858 



VDEVBLOK 
OEV OOC 
AODR 0339A8 



000 OOOCOOOO 20820000 OOOOOOCO OOOCOOOO OOOOOOCO 00000000 COOOOOOO OOOCOOOO 
020 C 1000000 00000008 OOOOOOCO 00059A48 OOOCOOOO OOOOOCOO 



VDEVBLOK 
OEV 000 
ADDR 0339E0 



COO OOODOOOO 10820000 OOOCOOOO 00000000 OOOOOOCO OOOOOOCO 00000000 00000000 
020 C 1000000 00010000 00000000 00059A48 00000000 OCOOOOOO 



VDEVBLOK 
DEV OOE 
AODR 033A18 



000 OOOEOOOO 10410000 00000000 OOOCOOOO OOOCOOOO OOOOOCOO COOOOOOO COOOOOOO 
020 C1000000 OOO1O0OO OCOOOOOO 00059A48 00000000 00000000 



VCUBLOK 000 00100000 OOOOOOCO FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFF= 

UNIT 01X 020 FFFFFFFF FFFFOOOO 
AODR 033948 

VDEVBLOK 000 OOOFOOCO 80000000 OOOOCOOO 00000000 OOCOCOCO COOOOOOO 0000B8F0 OOOCOOOO 
DEV OIF 020 OOOOOOCO 00000000 00000000 00059A48 00000000 00000000 
ADDR 033970 

VCONCTL 000 OOOOOCOO OOOOOOOC OOOOOCOO 00000000 OOCOOOOO OOOCOOOO 

ADDR OOB8F0 

VCUBLOK 000 00300000 OOOOOCOO 0OE0O118 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 

UNIT 03X 020 FFFFFFFF FFFFFFFF 
ADDR 033880 



VDEVBLOK OOC 00000000 60100000 OOOOOCOO OOOOOOOC COOOOOOO OCOOOOOO OCOOCOCO OOOCOOOO 
DEV 030 020. OCOCOCOO 00000000 00000000 00059A48 00000000 00000000 
ADDR 033A50 

VDEVBLOK 000 OOOIOOOO 80100000 00000000 00000000 OOOOOCOO 00000000 00000000 00000000 
DEV 031 020 OOOOOCOO OOOOOOCO OOOCOOOO 00059A48 OOOOOOOO 00000000 
AODR 033Ae8 

VCUBLOK 000 OOFOOOOO C0000080 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 

UNIT OFX 020 FFFFFFFF FFFF0150 
AODR 0338A8 

VDEVBLOK 000 OOOFOCOO 20400000 OOOCOOOO OOOOOOOC OOOOOOCO OOOOOOCO OOOOOOOO OOOCOOOO 
DEV OFF 020 OOOOOOOO 00000008 OOOOOOOO 00059A48 OOOOOOOC OOOOOOOO 
ADDR '033AC0 

VCHBLOK 000 C1000000 C0000080 FFFFFFFF FFFF0078 FFFFFFFF FFFFFFFF FFFF00C8 FFFFFFFF 

CHAN 1XX 020 FFFFFFFF FFFFFFFF 
ADDR 0599F8 

VCUBLOK 000 00300000 COOOOOOO 018801CO FFFFFFFF FFFFFFFF FFFF01C0 FFFFFFFF FFFFFFFF 

UNIT 13X 020 FFFFFFFF FFFFFFFF 
ADOR 0338D0 

VDEVBLOK 000 OOOOOOOO 0003A000 00000048 4CC4E2C3 06D5D5C5 C3E340C8 C5C1D3C4 40404040 
DEV 130 020 E4E2C5D9 E2407E40 F0F2F961 F7F24040 40404040 40404040 
ADDR 033AF8 



Figure 36,. Formatted VMFDUMP (Part 5 of 6) 
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SEGTABLE PAGTABLE 


S H P T 


ABLE 


00 F0073248 


0050 


00000404 


00311300 


1 


0020 


00010404 


00311700 


2 


0000 


00020404 


00311500 


3 


06C0 


00030404 


00311800 


4 


0009 


0004F4F6 


002E0C00 


5 


0010 


0005F4F4 


00311400 


6 


0009 


05060404 


002E0BO0 


7 


0009 


05070606 


002E0A00 


8 


0009 


05080404 


002E0900 


9 


0008 


40090000 


00050101 


A 


0008 


400A0000 


00050201 


B 


0009 


050B0404 


00100600 


C 


0008 


400COO0O 


00050401 


D 


0009 


0000F4F4 


00280000 


E 


0009 


000E0404 


002E0800 


F 


0009 


000FF4F4 


00350A00 


01 F0073308 


0060 


O000F4F4 


002E0100 


1 


OOCO 


0001F4F4 


002E0500 


2 


0009 


0002F6F4 


003E1300 


3 


0090 


0003F6F6 


002E0200 


4 


0009 


0004F4F4 


003B0200 


5 


0008 


40050000 


00050001 


6 


0008 


40060000 


00050E01 


7 


0008 


4007C000 


00000000 


8 


0009 


0008F4F4 


00320B00 


9 


0009 


0009F4F4 


002E0E00 


A 


0009 


450AF6F6 


00000000 


B 


0009 


000BF6F6 


00400200 


C 


0009 


050CF6F6 


00290E00 





0009 


0000F6F6 


00240900 


E 


0009 


050E0606 


00391700 


F 


0410 


000FF6F6 


00290F00 


02 F00733C8 


0009 


0000F6F6 


00380300 


1 


0009 


0001F6F6 


002B0A00 


2 


0009 


0002F6F6 


00290900 


3 


0009 


0003F6F6 


002C0600 


4 


0009 


0004F6F6 


00290000 


5 


05C0 


4005F6F6 


OOC32201 


6 


0009 


45060606 


00000000 


7 


0009 


4507F6F6 


00000000 


8 


0009 


45080606 


00000000 


9 


0009 


45090606 


00000000 


A 


0009 


450A0000 


00000000 


R 


0008 


40090000 


00000000 


C 


0008 


4OOCOOO0 


00000000 


D 


0008 


40000000 


00000000 


E 


0008 


400EOOOO 


00000000 


F 


0008 


400FOOOO 


00000000 



OE 00000001 NO PAGTABLE ENTRIES FOR THIS SEGMENT 
OF 00000001 NO PAGTABLE ENTRIES FOR THIS SEGMENT 



Figure 36. Formatted VMFDUHP (Part 6 of 6) 
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Index 



t (cent symbol) , line edit use 23 



I (attention symbol) 26 
sample usage 31 



# (pound symbol) , line edit use 23 



(At sign) , line edit use 23 



" (double quotes) , line edit use 23 



abnormal termination (abend) (see also 
YMEBOMP) 
dump 10 6 
access, virtual machine requirements 11 
address 

alteration 

console 24,28 
areas, error recording (s ee error 

recording cylinders) 
assistance, system operator 13 
At sign (3) , line edit use 23 
ATTACH, command, usage 24 
attached processor 

operation, results of uncorrectable 

errors 69 
summary of machine check handler action 

68 
system damage 65 
attention 

signaling, sample usage 26 
symbol (!) 

sample usage 26,31 



CCH (channel check handler) 
additional functions 72 
error messages 74 
function 66 
initialization 72 
overview 60 
reaction to errors 74 
summary 71,73 



CJS'S 

privilege class 14 

/systei operator, relationship 13 

use of IPCS 13 

virtual machine 

capabilities/limitations 3,5 
protective features 3 
typical configuration 14 
cent symbol (*) , line edit use 23 
channel check 

error record layout 56 

handling by SVC 76 41 

reflection to virtual machine 60 

system action 72 
channel check handler (s ee CCH (channel 

check handler)) 
checks, terminal facility 22 
class, privilege 16 
CHD command, BSCS usage 103 
CMS (Conversational Monitor System) 

prerequisite for CPEREP 16 

warning, file destruction 17 
codes 

line transmission 19 

wait state 74 
conditions, terminal communication line 22 
console functions, systems, CP command 

equivalency 3 
control block linkage 

environmental data recording 51 

fatal error 50 

I/O operation 44 

I/O retry 46 

SDH recording 47 

structure for sense byte analysis 45 

2305 environmental data recording 50 

3330/3340/3350 environmental data 
recording 51 
control units, line 18 

correspondence (line transmission code) 19 
CP commands, equivalency to system console 

functions 3 
CP nucleus, storage errors 62 
CPEBEP (see also EHEP) 

ACCDEV" 95 

ACCIB 95 

applications 96 

brief description of use 16,64 

CHS the environment for 16 

command entry 

file entry method 92 
mixed entry method 92 
prompting method 91 



Index 115 



command format 83-84 

consolidation of error recording from 
different systems 97 

DIRECTWK 95 

duplication of VS EREP's IFCOFFLD 
(offload) function 96 

edit facilities 16,64 

EREPPT 94 

FILEDEFs 94 

invoked, console entry methods 91 

operand entry, rules 91 

operands, brief descriptions 85-89 

OS/VS EREP overview 80 

OS/VS EREP relationship 79 

publication requirements for use 79 

screening of operands 80 

SERLOG 95 

shared I/O configuration changes 97 

SYSIH 94 

terminal session, anotated console 
listing 92 

TOURIST 95 

type of error records recorded 81 

use with HSS error records 16 

use with VS1/YS2 Subsystem Data Analyzer 
(SDA) Program 16 

user classes 82 

vs OS/EREP record formats 80 
CP-initiated I/O operation, error recovery 

63 
CP-owned volumes, linking to for test 

purposes 24 
cylinders (areas) , error recording 48 



damage to system, recovery attempts 64 
DiSD (Direct Access Storage Device) 

environmental data recording, sense data 
50 

error recording conditions 53 
DASD device, testing 24 
data, security 12 
DEFIHE, command (CP) , usage 24 
destruction, file 12 
devices, supported, line equipment 18 
diagnostic tests (see OLTSEP (Online Test 

Standalone Executive Program)) 
differences/exceptions, OS/YS EREP vs 

YH/370 EREP 82 
double error recording 64 
dump 

device specified by SET coamand 106 

system 106 



64 



38 



ECHO command 

sample printout 34 

used fcr terminal checkout 34 
editing 

error records, CPBREP 64 

input line 23 
EREP (see also CPEREP) 

CPEREP equivalency 16,64 

CPEREP relationship 79 

data set requirements 93 

reports, operand requirements 91 
error checking and correction (ECC) 70 
error handling overview 37 
error messages, to operator 44 
error recording 

conditions, specific devices 53 

CP modules used 43 

cylinders (areas) 

editing error records 
full condition 48 
virtual machine owned 

dedicated devices 39 

differences 39 

edit facilities 16,61 

functions 48 

outboard recordings 48 

record format 53 

relationship of I/O configuration to 
DHKRIC and MSC Table Create Program 39 

SVC 76 63 

types of errors 38 

virtual vs real addressing 

virtual vs real device type 
error recovery 

CP-initiated I/O operations 

features, introduction 60 

from soft machine checks 62 

functional 67 

I/O, detailed description 44 

levels 67 

machine check, hard 61 

modes 70 

operator-initiated restart 68 

procedures 63 

processor errors 61 

processor retry 37,67 

protection key errors 62 

storage error 61 

system 67 

system repair 68 

user termination 67 

virtual machine initiated I/O operations 
63 



39 
39 

63 



116 IBH YK/370 OLTSEP 6 Error Recording Guide 



errors 
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handling by S?C 76 41 

ref lection- to v ir tu al machine 60 

system action 72 
correction cede (see error checking 

correction (ECC) ) 
I/O, discussion 37 
■achine check, system action 67 
messages, CCH, a referral 74 
record fields, source of data 57 
record formats 

channel checks 56 

header layout 58 

machine checks 56 

nonstandard 55 

unit check (short form) 55 
record layout, unit check 55 
record modifications, SVC 76 42 
reflection 37 
types recorded 38 
EXTERNAL, command, example of use 28 



F privilege class 16 
failure (see also errors) 

line 22 

logon 23 
fatal error, control block linkage 50 
FILEDEFs for CPEEEP 94 
files 

destruction 17 

protection 12 

security 12 
formats, error record (s ee record, 

formats) 
frames, SBF (Service Record File) , 

description 48 
FRIEHD 

OLTS 28 

sample printout 28 



G privilege class 14 



hardware problem analysis 

from a queued system task,, 

advantages/disadvantages 2 
from the dedicated real system, 

advantages/disadvantages 1 
from the virtual machine - 

advantages/disadvantages 3 
header 

layout, error record 58 

record, error, source of data 59 



inboard error recording (see Recovery 

Management Support (RMS)) 
input, line editing 23 
intensive recording mode 14,52,98 
I/C 

devices, specifying, error recording 98 
environmental data recording 50 
2305 control block linkage 51 
3330/3340/3350 control block linkage 
51 
error recording 

penanent error 50 

structure for sense byte analysis 45 
errors (see also hardware problem 
analysis) 

control blocks linkage I/O retry 46 
DJSD error conditions 53 
discussion 37 
intensive recording 52 
maintenance from a virtual machine, 

statistical evaluation 4 
message to operator 44 
recovery, detailed description 44 
SDR recording 49 
operations 

control block linkage 44 

CP 37 

virtual machine 37 

minidisk 24 
terminals 25 
IPCS (Interactive Problem Control System) , 
CE usage 13 



H 

hardware maintenance 

virtual machine, overview 1 
VH/370 essential requirements 9 



Index 117 



L 
line 

devices supported by VM/370 18 
editing 23 

terminal facility check 22 
transmission 
codes 18 
tables 18 
line control units 18 
line delete, logical edit symbol 23 
LIHK command, use for testing CP-owned 

volumes 24 
log records, SML 104 
logging errors, determination for error 

recording 38 
logical line delete 23 
logical line end, edit symbol 23 
logon 

a prerequisite for testing 21 
correspondence versus EBCD/PTTC codes 

20 
failure 22 

messages 23 
successful 22 
logout, storage assignment 75 



machine check 

error record layout 56 

hard, recovery 61 

soft, error recovery 62 
machine check handler (s ee HCH (machine 

check handler) ) 
malfunction ( see errors) 
MCH (machine check handler) 

description 66 

function 66 

overview 60,66 

reaction to error 67 

summary 68 

with attached processor application 68 
MESSAGE command 

sample printout 33 

use as an aid to logon 22 

used for terminal checkout 32 
messages 

error, CCH, a referral 74 

to operator 44 
minidisk testing 24 
mode 

intensive recording 14 

system recovery (see recovery, mode) 
modifications, error record, SVC 76 42 
MONITOR command, trace data 106 
MSG command (CP) (see MESSAGE command) 



HETRORK command, TRACE operand, brief 

description 103 
nonstandard record layout, error record 

layout 55 
notional conventions, brief description 82 



OLTS (Online Test Sections) 25 
example of printout 25 
invoking 22,24 
maintaining 9 

test runs from the virtual machine 4 
testing the virtual console 27 
virtual machine vs standalone system 
environment, test results analysis 4 
OLTSEP (Online Test Standalone Executive 
Program) 

initialization 11,22 
maintaining 9 

OLTS (see OLTS (Online Test Sections)) 
OLTSEP-RETAIR, invoking 30 
OLTS/FRIEBD 28 

sample printout 28 
testing, operator assistance 28 
Online Test Sections (see OLTS (Online 

Test Sections) 
Online Test Standalone Executive Program 
(see OLTSEP (Online Test Standalone 
Executive Program)) 
operands 
CPE REP 

brief description 85-89 
required for reports 91 
CPEREP format 83-84 
operating system, recognition by S7C 76 41 
operator (se e system operator) 
OS/VS EREP (iee EREP) 



parameters, passing 41 

permanent, I/O error, error recording 50 

pound symbol (#) , line edit use 23 

prerequisites, OLTS 21 

printout 

sample of ECHO 34 

sample of FRIERS 28 

sample of MESSAGE usage 33 

sample of OLTS 25 

sample of RET AIR , 31 
privilege classes, CE's 16 
problem analysis (see hardware problem 
analysis) 

froi the virtual machine 3 
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rocessor errors, VM/370 recovery 61 

irocessor retry 37. 67 

rotection key errors, error recovery 62 



IUERY, command (CP) , example of use 28 
[uiet recording mode 71 



I 

real machine vs virtual machine, hardware 
maintenance 1 

recording, intensive mode 52 
recording modes (see also SET command (CP) 
BECOBD operand) 

recording of error records, type recorded, 
YM/370 vs 0S/YS2 81 
records, format, error recording 53 
recovery ( s ee error recovery) 
Recovery Management Support (HMS) 

damage assessment 68 

objectives 66 

summary of functions 66 

uncorrectable errors, machine check 69 

VH/370 support 66 
[relationship, CE/system operator 13 
requirements, for testing virtual machine 

11 
ceset, intensive recording 99 
cestart 

after system damage 64 

operator-initiated 68 
BETAIH 

procedures, invoking 30 

sample printout 31 
retry 

processor 37,67 

via SET MODE command 99 
EMS (s ee Recovery Management Support) 
ESCS (Remote Spooling Communications 

Subsystem), tracing the line 103 
rules, CPEREP operand entry 91 



SDR (Statistical Data Recorder) 

record layout 55 

VM/370 usage 47 
SDR recording, initiated by SHOTDOWH 49 
security, data (file) 12 
sense data, DASD environmental recording 

50 
Service Record File (see SRF) 



SET command (CP) 
MODE operand 

description 99 
th re shh eld count 100 
usage 62,70 
use 99 
RECORD operand 

description 98 
exaaples 99 
usage 52 
SML (Spool MULTI-LEAVIHG) , log records 104 
soft errors 

count control 70 
explanation 68 
limiting 70 

recording at system initialization 70 
SRF (Service Record File) 
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frames, description 
starter system 21 
storage, assignments, logout 
storage errors 
CP nucleus 62 
system recovery 61 
STORE, coiBmand, example of use 
supported systems, SVC 76 40 
SVC 76 

description 40 
error record modifications 
type DDR 43 
type MDR 43 
type MIH 43 
type OBR 42 
type program abend 42 
error recording 63 
requirements 38 
functions 40 

handling of channel errors 
operating system recognition 
parameter passing 41 
systems support 40 
system 

configuration 
■inimum 21 
21 



75 



28 



42 



41 



41 



starter 
dump 106 
repair 68 
termination 



67 



system console functions, CP command 
eguivalency 3 

system damage 

attached processor recovery 65 
attached processors, affinity reset 
system restart facilities 64 



65 



Index 119 



system operator 

aid from 13 

assistance 13 

/CE relationship 13 
SYS1. LOGREC (see error recording) 



user 

terminals 18 

termination, error recovery 67 
user class required, CPEHEP 82 



24,28 



18 
18 



terminals 

address alterations 

check 

via ECHO 3a 
via MESSAGE 32 

supported by VM/370 

transmission codes 
termination, system operation ( see fatal 

errors) 
test (s) 

diagnostics ( see OLTSEP (Online Test 
Standalone Executive Program)) 

line transmission code 19 

MESSAGE command 23 

minidisk 24 

system check, basic 22 
testing, from a virtual machine 11 
threshhold count, SET MODE 100 
trace 

HETWOBK command, brief description 103 

HSCS line 103 
THACE command (CP) (see also HETWOBK 
command TRACE operand) 

described 101 

invoking, examples 101 

output 101 

printout segment 102 
trace table, MONITOR command 106 
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virtual machine 

a tool for I/O problea analysis, 
statistical evaluation 4 

as troubleshooting aid 1 

CE»s 

capabilities/liiitations 3,5 
protective features 3 

error recording 39 

error recording cylinders (areas) 38 

I/O error recovery 63 

results of uncorrectatle errors 69 

the CE's 14 
Virtual Machine Facility/370 (VM/370) 

error recording, differences 39 

online message, 3704/3705 22 

recovery features 

channel check handler 60 
machine check handler 60 

support, RMS 66 

system, recovery 67 
VHFDOMP command 

description 106 

sample of output 108 



wait state codes 74 



uncorrectable errors 
machine check 

attached processor action 69 
uniprocessor action 69 
system action 69 
unit check 

( see also error handling) 
error record layout 55 
error record layout (short form) 55 
error recordings for 2305, 3330, 3340, 
3350 53 



3277, OLTS testing 26 
3704/3705, VM/370 online message 
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